Running Claude Code Tasks in Parallel Without Losing Track

To have Claude Code run tasks in parallel, give each session its own git worktree with claude --worktree <name>, dispatch background sessions from agent view with claude agents, or let one session hand independent pieces to subagents. Those tools solve the file problem: two sessions no longer write over each other. They do not solve the coordination problem: which session is doing which job, and whether two of them have started the same one. For that you need one list that every session reads before it starts and writes to when it stops. A board works well: each session pulls a different card, claims it by moving it to In Progress with a comment, and reports the result on the same card.

The ways Claude Code runs work side by side

Claude Code’s documentation↗ (opens in a new tab) lists several approaches, and they differ in who coordinates the work:

• Parallel sessions in worktrees. You open several terminals and start each with --worktree (or -w). Each gets its own checkout under .claude/worktrees/<name>/ on a new branch called worktree-<name>. You drive each one.
• Background sessions. claude --bg "<prompt>" starts a session that runs without a terminal attached, and claude agents opens agent view↗ (opens in a new tab), one screen showing every background session and whether it is working, needs input or is done. Agent view is a research preview.
• Subagents. One session delegates side jobs to workers with their own context, which report back a summary. Several can run at once.
• Agent teams. A lead session splits the work and teammates share a task list↗ (opens in a new tab). Experimental, off unless you set CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1.
• /batch. A bundled skill that splits one large change into 5 to 30 units and runs each as a background subagent in its own worktree.

# Two sessions you drive, each in its own checkout
claude --worktree bu-042
claude --worktree fe-051

# One you hand off and check on later
claude --bg --name "en-017" "Work on ENH-017 from the board"
claude agents

The documentation is plain about the cost: running several sessions or subagents at once multiplies token usage, and each background session draws on your plan’s usage on its own. Three sessions is three times the spend, so parallel is for work that is genuinely independent, not a way to go faster at one thing.

Collision one: the same files

Two sessions in one checkout will edit the same files, run the same dev server and trip over each other’s half-finished changes. Worktrees are the documented fix↗ (opens in a new tab). A worktree is a separate directory with its own files and branch, sharing the repository’s history, so an edit in one session never touches another.

• Add .claude/worktrees/ to .gitignore, as the docs suggest, so worktree contents do not show up as untracked files in your main checkout.
• A worktree is a fresh checkout. Install dependencies in it, and list gitignored files such as .env in a .worktreeinclude file at the project root to have them copied in.
• For subagents, add isolation: worktree to a subagent’s frontmatter, or ask Claude to use worktrees for its agents.
• Agent teams do not isolate teammates in worktrees. The docs say to split the work so each teammate owns a different set of files.

Worktrees move the conflict rather than remove it. Two branches that change the same function still meet at merge time. The cheapest prevention is upstream: cards that touch one area each, so two parallel sessions are rarely in the same file to begin with.

Collision two: the same card

Open two terminals and tell both “fix the next bug”. Each reads the same list, reaches the same conclusion and starts the same fix, in separate worktrees, perfectly isolated from each other. The file tooling cannot see this, because nothing is wrong with the files. The waste is in the intent.

Agent teams handle it inside a team: their shared task list uses file locking so two teammates cannot claim the same item. But that list belongs to one team on one machine. Sessions in separate terminals, a colleague’s session, or a different assistant such as Cursor do not see it. Across all of those, the claim has to live somewhere every session reads.

One board as the source of truth

The protocol is short, and every session follows the same one:

1. List the Next Up lane. Skip anything already in In Progress; a card there is claimed.
2. Take the top card and move it to In Progress. The move is the claim.
3. Comment straight away: which session you are, the worktree or branch, and what you are about to do.
4. Read the card back. If another session’s claim comment is there ahead of yours, move on to the next card.
5. Work. When you finish, comment what changed, the commit and the check you ran, and move the card to Completed. When you stop, comment why and move it back to Next Up.

Step four is there because a board is not a lock. Moving a card to In Progress takes no lock in fenbs (only a task a person has pre-approved for AI is held for one assistant, through fenbs_next_approved_task); two sessions that move the same card in the same second will both succeed, and the history will show both moves. The comment is what makes the race visible and cheap to lose. In practice it is rare, because the next rule removes most of it.

## Parallel sessions and the board
- If I gave you a ref, work on that card only. Otherwise:
  list lane "next", skip anything in "doing", take the lowest priority number.
- Move it to "doing", then comment: "Claimed by <worktree name>. Plan: ..."
- Call fenbs_get_item on it. If another claim comment came first, pick again.
- One card per session. Never touch a card in "doing" you did not claim.
- Finished: comment the change, the commit and the check; move to "done".
- Stopping: comment where you got to; move it back to "next".

Assign, then there is nothing to race for

Racing for cards is the fallback. The cleaner pattern is to decide who does what before anything starts: name the worktree after the card and give its ref in the first prompt. claude "query" starts an interactive session with an initial prompt↗ (opens in a new tab), so:

claude --worktree bu-042 "Work on BUG-042 from the board. Follow CLAUDE.md."

Now the branch is worktree-bu-042, the session knows its card, and anybody looking at the board or the branch list can match one to the other. Background sessions take the same trick with --name, which is what agent view shows on the row.

Subagents follow the same idea one level down: put the card’s ref in the delegation and have the result commented on that card. The details are in Claude Code Task tool vs subagents.

Telling the sessions apart afterwards

Every session connected through your account acts as you, so fenbs records them all the same way: “Claude via <your name>”. The history tells you it was an assistant rather than you, not which session. That is why the claim comment names the session. Read a card’s comments in order and you get “Claimed by bu-042”, then the result, then the move, which is enough to trace any change back to a worktree and its branch.

At the end of the day, the board and the tools answer different questions. claude agents tells you which sessions are still running. The board tells you what each was for and what came of it. A card sitting in In Progress with no running session behind it is an abandoned claim: read its last comment, and move it back to Next Up so the next session can take it.

How many at once

Start with two. Parallel sessions are only as useful as your ability to review what they produce, and the review is the part that does not parallelise. If the Completed lane is filling faster than you can check it, you have too many sessions, not too few. Keep one card per session, and let the queue in Next Up, not the number of terminals, set the pace. The lane rules behind this are in a kanban board for Claude Code.