Git Worktrees for Parallel Agents
Run two agents on the same repository at once and they share one set of files on disk. A git worktree gives each one its own checkout instead: separate directories, each on its own branch, all backed by the same repository and history. Neither agent can see or clobber the other's edits, because they aren't editing the same files.
In this guide
What goes wrong without one
Two subagents running in parallel have no channel between them and no awareness of each other. Point both at the same working directory and tell each to edit config.py, and whichever finishes last writes over the other's work. Nothing errors. No conflict is reported, because as far as git is concerned one sequence of edits happened.
That makes it worse than a merge conflict, which at least stops and asks. Silent loss shows up later as a change that was definitely made and is definitely gone.
The usual first instinct is to tell the agents to stay out of each other's way. That works until one of them decides a shared file needs touching — and the whole reason to run an agent is that it decides things you didn't plan.
What a worktree actually is
A normal clone has one working directory. git worktree add ../feature-x feature-x creates a second one at that path, checked out to that branch. Both read and write the same repository underneath, so a commit made in one is immediately visible to the other — but the files on disk are separate copies.
Git refuses by default to check out the same branch in two worktrees at once, which is what stops two agents landing on the same branch by accident. Treat it as a strong default rather than an invariant: git worktree add --force overrides it, and an agent inside its own tree can still switch branches. The isolation holds as far as the agent's command permissions do, and no further.
Claude Code is one implementation of this pattern — it can spawn an agent into its own worktree and clean the tree up afterwards if nothing changed. The underlying git feature is ordinary and has nothing to do with AI; what's new is having several non-human workers who all want to edit at once.
What it costs
A second working directory is a second copy of every file, so disk use scales with the number of trees. That's usually trivial for source code and less so for a repository carrying large assets.
The bigger cost is that installed dependencies normally don't come along. node_modules, a Python virtual environment, a build cache — these live in the working directory, so a fresh worktree starts without them and something has to install or link them before an agent can run anything.
And the work still has to come back together. Each agent ends on its own branch, which means a merge, a review, and the ordinary chance of conflicts at the end. Worktrees move the collision from "silently during" to "visibly after," which is a much better place for it, but they don't remove it.
When it's overkill
Skip it when the agents only read — a review pass, a search, anything that produces findings rather than edits, can safely share one checkout. Skip it for sequential work, where each agent finishes before the next starts and there's nothing to collide with.
Skip it too when parallel agents genuinely own separate files and you can be confident of that. The deciding question isn't how many agents are running, it's whether two of them could write the same path. If the answer is no, a worktree is setup cost for a problem you don't have.