Claude Code worktrees: fifteen agents in London, and the merges blocked each other

I was in London, at work, running 15 parallel Claude Code agents.

Scoping and planning felt smooth.

Review became a nightmare.

The merge conflicts overlapped.

Merging one pull request blocked the others.

I spent more time on review than on every step before it.

I had gone from over-planning to over-reviewing

I listened to Matt Pocock's conversation with Robert C. Martin.

What I took from it was frequent review, in small slices.

I was reviewing one pile, after all 15 agents had already written.

I split the work now.

Each agent gets the same attention.

Each agent gets the tickets around the work

The plan goes out with the context around it.

That context is the tickets.

• Tickets already in flight.
• Tickets that block this one.
• Tickets I am not working on.
• Comments shared across the tickets and the worktrees.

I revise the plan in Claude Artifacts

This is my practice.

An artifact opens beside the conversation, and you ask Claude to change it.

That line is from Anthropic's help center, read on 2 November 2026.

I use Claude Artifacts to talk a plan through and change it over time.

The agent asks what I am working on.

I answer.

It tells me what it was thinking.

We combine the two.

My plan skill checks the other worktrees

This is my practice too.

My plan skill has the context of my other worktrees.

It notices when another worktree is already open.

It checks the linked tickets, and whether they are related.

I set a limit so the pull requests stay bite-sized.

When the estimated work is too big, the skill suggests another worktree or another ticket.

I comment on the plan whenever I see it.

I improve the skill over time.

Git worktrees give each Claude Code agent its own checkout

A git worktree is a second working directory for one repository.

It has its own files and its own branch, and it shares that repository's history.

git worktree add creates it.

Git refuses to check out a branch that another worktree already has, unless you pass --force.

The docs' example, claude --worktree feature-auth, creates a directory under .claude/worktrees/, named with the argument you passed, on a branch named worktree- plus that argument, and starts Claude there.

A second terminal, with a different name, starts the second session.

Leave the name off and Claude picks one, such as bright-running-fox.

Add .claude/worktrees/ to .gitignore.

The first claude in a directory is where you accept the trust dialog.

--worktree exits if that dialog has never been accepted.

A -p run skips the check.

A worktree stays inside the repository you started from.

New worktrees branch from the default branch on the remote.

That is worktree.baseRef set to "fresh", the default.

Set it to "head" when the new session has to start from the branch you are on, including commits you have not pushed.

The setting accepts those two values.

For a branch that already exists, create the worktree with git:

git worktree add ../repo-fix-list -b fix-list
cd ../repo-fix-list
claude

A worktree is a fresh checkout.

Gitignored files stay behind unless .worktreeinclude names them, and a match is copied only when it is also gitignored.

While the session is in the worktree, Claude Code blocks an edit aimed at the main checkout, and a git command that points back at that checkout.

A shell copy into the main checkout, with no git command, sits outside those checks.

In how I use Claude Code I wrote that every concurrent session or subagent runs in its own worktree.

The parallel agents page names the cases.

A session you start can have a worktree.

A subagent gets one with isolation: worktree.

Agent teams do not put teammates in worktrees.

These commands are from the worktrees page and the git page above, read on 2 November 2026.

The brief is the task, the files, the decision, and the stop

One session found two bugs, in two repositories.

It started a git worktree for each fix, with a fresh agent in each.

Every brief had four parts.

The task.

A verified background, with file paths.

The decision already made.

Numbered steps.

Two steps were in every brief: "Tell me the rule you chose and why before you build it" and "Ask me for the ticket key before you name the branch or commit."

The block is that shape, filled in with a generic task.

Task
Stop a failed item from looking like a success.
 
Background
Verified by reading these files:
- app/list.tsx renders one row for each item in the response.
- api/list.ts builds that response.
 
Decision already made
The check belongs in the API. The page renders what the API returns.
 
Steps
1. Tell me the rule you chose and why before you build it.
2. Ask me for the ticket key before you name the branch or commit.
3. Change the API so it matches the decision.

A new session has none of the investigation transcript.

A default worktree has none of the uncommitted files from the checkout you were in.

The frontend agent planned a warning label

This is my judgement of that session.

The frontend agent planned a warning label.

I pushed back.

The warning cannot work when the backend drops those items first, because the page never receives them.

The fix changed before any code was written.

The backend agent found that the rule needs a change in a shared package too.

It asked before it touched two repositories.