When subagents only read, running them together is easy. When they make changes, sharing one working directory gets risky, since two agents editing the same files will collide. A git worktree solves this by giving each line of work its own checkout.
What a worktree is
A git worktree is a second working directory tied to the same repository, checked out to its own branch. Changes in one worktree do not touch the files in another. Git supports this natively, so you can have several checkouts of the same repo side by side.
Why it helps subagents
Some setups isolate an agent in its own worktree. The agent gets a full working copy to edit freely, on its own branch, without disturbing your main checkout or another agent's. This lets you run parallel branches of work at once: one agent tries approach A in its worktree while another tries approach B in a different one, and you compare the results.
A simple setup
You create worktrees with git, one per branch you want to work on in parallel:
git worktree add ../feature-a feature-a
git worktree add ../feature-b feature-b
Each directory is a separate checkout. Point a Claude Code session or agent at one, and its edits stay contained there.
When to bother
Reach for worktrees when you want genuinely parallel change work rather than parallel reading. For read-only investigation, plain subagents already keep contexts separate and need no worktree. When agents are editing, worktrees keep their changes from overwriting each other, and merging happens later through normal git.
Comments
Be the first to comment.