Two AI coding agents working in the same repository folder will fight. One renames a function while the other is halfway through editing the file that calls it. Tests pass for one and fail for the other because the working tree changed underneath them. The moment you run more than a single autonomous agent against a checkout for more than a few minutes, a single working directory stops being viable. Git worktrees are the boring, built-in fix, and they became load-bearing infrastructure for AI-assisted development over the first half of 2026.
This isn't a new Git feature. git worktree shipped back in 2.5 (2015). What's new is the reason everyone suddenly cares: Anthropic's Claude Code docs recommend worktrees for multi-session work, Cursor built its Parallel Agents feature on top of them, and GitHub Copilot CLI's autopilot mode assumes each agent gets its own isolated tree. The pattern stayed niche for a decade and then became standard practice almost overnight.
Why one working directory breaks down
A normal clone gives you exactly one working tree. Every branch checkout mutates the same files on disk. That's fine for a human who context-switches a few times a day. It falls apart when you have two or three agents that each want to read the codebase, edit files, run the test suite, and iterate to completion without anything shifting underneath them.
The naive workaround is cloning the repo multiple times. That works, but it's wasteful: each clone re-downloads history and stores its own .git. On a large monorepo that's gigabytes per copy and a slow fetch for every one of them.
The mental model
A worktree is a second working directory attached to the same repository. All your worktrees share one .git object store, so history, refs, and fetched objects exist once on disk. Each worktree checks out a different branch and has its own index and its own files. Switching branches in one has zero effect on the others.
That shared object store is the whole point. Creating a worktree is nearly instant and costs almost nothing beyond the checked-out files themselves, because there's no second copy of history.
A workflow that scales to a few agents
Give each agent its own worktree on its own branch:
# create a new worktree on a fresh branch
git worktree add ../app-refactor-auth -b agent/refactor-auth
# see everything that's checked out and where
git worktree list
# when the branch is merged, retire the tree
git worktree remove ../app-refactor-authSpinning up several at once is a one-line loop:
for task in refactor-auth fix-flaky-tests add-csv-export; do
git worktree add "../app-$task" -b "agent/$task"
donePoint each agent at its directory and let them run. Because the branches are independent, two agents touching the same file produce a normal merge conflict at review time instead of a corrupted working tree at runtime.
Housekeeping that actually matters
The sharp edges are not in Git itself but in everything around it.
Dependencies are not shared. Each worktree is a separate folder, so node_modules, Python virtualenvs, and build caches do not carry over. You need an install step per tree. With pnpm the global content-addressed store keeps this cheap, but you still run the install:
cd ../app-refactor-auth && pnpm installUntracked files do not copy either. A .env.local that lives in your main checkout will not exist in a new worktree, and that's a common reason an agent's first test run fails for no obvious reason. Copy what's needed explicitly:
cp .env.local ../app-refactor-auth/.env.localClean up stale state. If you delete a worktree folder by hand instead of using git worktree remove, Git keeps dangling metadata. git worktree prune clears it. You also can't check out the same branch in two worktrees at once — Git refuses, which is a feature, not a bug.
Where it stops paying off
More agents is not linearly better. In practice the ceiling on a modern laptop is somewhere around five to seven concurrent agents before disk consumption, provider rate limits, and the human cost of reviewing all those branches cancel out the throughput gains. Worktrees remove the file-system contention; they do nothing about the fact that a person still has to read every diff. Treat the worktree as the cheap part and your review bandwidth as the real constraint.
If you're running even two coding agents today and still pointing them at one folder, switch. Three commands — add, list, remove — plus a prune when you get sloppy, and the entire class of "the agents stepped on each other" bug disappears.