The most important thing about Claude Code's Tasks feature is not the task list — it is where the task list lives. When Anthropic upgraded Todos to Tasks in v2.1.16 (January 22, 2026), the headline change was that task state moved out of a single session's memory and into files on disk, under ~/.claude/tasks. I can tell you exactly why that matters, because before Tasks existed I had already built the same mechanism by hand to push an 84-post content rewrite through production, and the file-backed manifest was the difference between a pipeline that survived crashes and one that lost work every time a session died.
That experience is the lens for this post: what Tasks actually change, and the operational rules that make parallel execution across sessions work — rules I learned the manual way.
What changed, concretely
The old Todo system was session-bound. Close the session, the list is gone. Spawn a subagent, and it has no idea what the main agent was tracking. Fine for a single sitting; useless for real projects.
Tasks are a different primitive:
- File-backed. Task state persists on disk and survives session restarts.
- Shared. Multiple sessions and subagents can watch and update the same list, and updates propagate to everything watching it.
- Stateful. Tasks carry explicit states — pending, in progress, completed, blocked — and can depend on each other, so a blocked task encodes an execution pipeline, not just a checkbox.
- Tool-driven. Sessions manipulate the list through structured tools (TaskCreate, TaskUpdate, TaskGet, TaskList) rather than a free-text scratchpad.
If you have ever tried to coordinate two terminal sessions on one project by pasting context between them, this is the fix for exactly that.
The war story: I ran this pattern before it shipped
Last month I pushed a surgical SEO rewrite across 84 blog posts on this site — seven batches, multiple Claude Code sessions across multiple days, applied against a production database. The coordination problem was precisely the one Tasks solve: how do parallel and sequential sessions share one source of truth about what is done?
My answer was a durable manifest: a REWRITE-STATUS.json file with every post ID marked DONE or PENDING, plus a small mark_done.php script as the only writer. Every session — mine or an agent's — started by reading the manifest and ended by updating it. When a session crashed mid-batch (and over several days, sessions crash), the next one resumed from the manifest instead of re-analyzing the world. The pipeline currently rewriting this very post works the same way, scaled up: a graph of worker nodes, a status file, per-batch assignments, and file-backed state everywhere.
Running that pattern manually taught me the operational rules that no feature announcement will tell you. They apply directly to Tasks.
Rule 1: The worker marks completion, at the moment of completion
The single most important crash-resume rule: state must be updated by the process that did the work, immediately after the work, not by an orchestrator summarizing at the end. If the orchestrator batches up status writes and dies, the manifest lies — it says work is pending that is actually done, and your next run duplicates it. In my rewrite pipeline, mark_done.php ran after each post was applied, not after each batch. With Tasks, the equivalent discipline is instructing subagents to update their own task status as they finish, rather than having the parent session sweep up afterward.
Duplicated work sounds harmless until the work has side effects — database writes, published content, sent messages. Then idempotency becomes your second line of defense, which is rule 2.
Rule 2: Make every task safe to run twice
Assume the task list will occasionally be wrong — a session died between doing and marking. Every worker in my pipelines is idempotent: apply scripts check current state before writing, use ID-and-slug guards, and wrap changes in transactions. If a "completed" task runs again, nothing breaks. This is boring engineering, and it is the entire reason I can let sessions run unattended. A shared task list without idempotent tasks is a machine for turning crashes into data corruption.
Rule 3: Partition by range, not by negotiation
When multiple sessions work one list in parallel, the tempting design is letting each agent "claim the next available task." Claiming requires locking, and locking across independent sessions is where subtle double-work bugs live. The design that has never failed me is static partitioning: worker A gets items 1–25, worker B gets 26–50, assigned up front. My current pipeline hands each worker an explicit index range in its briefing. Task dependencies handle the sequential parts; ranges handle the parallel parts. Dumb, and therefore reliable.
For the physical side of running parallel sessions — separate working copies so agents do not trample each other's files — the setup I use is covered in Claude Code with git worktrees for parallel agents.
Rule 4: The task list is not the memory
Tasks tell the next session what remains, not why the project is shaped the way it is. Pair the task list with a small set of durable context artifacts: a status document with decisions made, reports each phase produces for the next, and a resume-friendly directory layout. The handoff between sessions is a real design problem — the handoff pattern for multi-session Claude Code work covers the context half, and for long-lived knowledge that outlasts any project, I keep a persistent memory system alongside Claude Code. Tasks replaced my hand-rolled manifest; they did not replace the reports and status docs around it.
When Tasks earn their keep — and when they are overhead
Where they pay:
- Multi-session projects. Anything you will not finish in one sitting. The resume experience — new session, reads the list, continues — is the feature.
- Subagent fan-out. A parent decomposes work, subagents execute in parallel against the shared list, states propagate. This is the small-scale version of what I do with worker pipelines; when the fan-out gets large enough to need architecture, that is agent swarm territory.
- Blocked-on dependencies. Encoding "migrations before seeding before tests" as dependencies means parallel workers cannot start things whose prerequisites are open.
Where they are overhead: single-session fixes, exploratory work where the plan changes every ten minutes, and anything small enough that writing the tasks costs more than the coordination saves. A one-hour refactor does not need a persistence layer.
The takeaway
Anthropic productized the correct pattern — I know it is correct because I was already running it in production out of necessity, with JSON files and a PHP script, before the feature existed. What the feature cannot productize is the discipline around it: workers mark their own completion, every task is idempotent, parallelism is partitioned up front, and durable context travels alongside the list. Get those four right and parallel execution across sessions stops being a demo and becomes how you ship.
Batch pipelines with crash-resume, idempotent tasks, and partitioned parallelism are a recurring piece of my client work; the 84-post rewrite described above is one instance of the pattern. My services page covers how that kind of build usually runs.
