One agent per branch. Git worktrees with Claude Code.

My git workflow was serial for twenty years. One checkout, one branch at a time, git stash when something urgent landed mid-feature, and a quiet grumble every time the stash pop conflicted with itself. Then coding agents arrived, and the bottleneck stopped being me. It was the working directory. Two agents in one checkout fight over the same files, the same build output and the same dirty state, and you spend your time refereeing instead of reviewing.

The fix has been in git since 2015: git worktree. It never got the adoption it deserved because one person at one keyboard rarely needs two checkouts. Two agents at one keyboard need them constantly.

The cheat sheet

# new worktree + branch in one step
git worktree add ../app-feature -b feature/login

# worktree for an existing branch
git worktree add ../app-hotfix hotfix/css

# what exists
git worktree list

# done with it
git worktree remove ../app-feature
git worktree prune

One repository, many folders. Every worktree is a full working tree with its own checked-out branch, sharing the object store and refs with the main checkout. No re-cloning, no re-fetching, and a branch checked out in one worktree cannot be checked out in another — which is exactly the guardrail you want when two agents are involved.

The agent workflow

The loop that stuck: issue comes in, I create a worktree for it, open a terminal in it, and start Claude Code there. Another issue, another worktree, another session. Each agent sees a clean tree, builds and tests against its own files, and the diffs never interleave. The Claude Code documentation now recommends exactly this for parallel sessions, and newer versions have grown their own worktree helpers — but the plain git commands above are all it takes.

Review got better as a side effect. Each worktree is one issue, one branch, one diff. I review it, merge it, remove the worktree. git worktree prune takes the husks with it.

Worktree vs branch vs clone

• Branches are serial. One working tree, switch when context changes, stash what you were doing. Fine for one brain, wrong for several agents.
• Multiple clones work but duplicate everything: the object store, the remotes, the fetches. Disk is cheap until you do this five times a week.
• Worktrees are parallel trees over one repository. Shared history, independent files. This is the middle the other two were missing.

The honest trade-offs

• Untracked files do not follow you. .env is not in git, so it is not in the new worktree. Copy it or watch the agent fail on the first boot with a mystery it will happily spend ten minutes inventing causes for.
• Dependencies reinstall per worktree. node_modules, .venv, target — each tree needs its own install. A store-based package manager such as pnpm softens it; nothing eliminates it.
• Ports collide. Two dev servers on 3000 is a fight the second agent loses confusingly. Parameterise the port or stagger the runs.
• Long-lived worktrees rot. The branch moves on, the worktree stays behind. Treat them as disposable — make one per task, remove it when merged, and let prune handle the litter.
• Your IDE sees each worktree as a new project. Indexing cost, per folder. Open the worktree you are reviewing, not all of them.

Where it landed

The stash habit is gone. Context switches used to cost a stash, a pop, and occasionally a small conflict archaeology session; now they cost cd. Worktrees spent a decade as a solution looking for a problem. Agent parallelism is the problem, and it was already solved — the commands were just sitting there in git, waiting for something to fill the second checkout.