The moment you run two coding agents against the same repository at the same time — one fixing a bug, one adding a feature — they share a single working tree by default: one set of files on disk, one index, one currently-checked-out branch. Agent A edits a file while Agent B is mid-edit on the same file, or A runs the test suite while B has half-applied a refactor, and the failure isn't a merge conflict you can resolve after the fact — it's corrupted-looking output from both agents while they were still running, because there was never two of anything to keep separate.
git worktree add ../repo-feature-x feature-x checks out feature-x into a second directory that shares the same .git object database as the original. Each worktree gets its own working directory, its own index, and its own currently-checked-out branch — that's the whole mechanism. Two agents in two worktrees can edit, build, and run tests fully in parallel with zero risk of one seeing the other's half-finished file, because "the file" is now two different files on disk until someone merges.
What it does not give you: separate commit history (both worktrees still push to branches in the same repo, so a rebase in one can still affect what the other sees on shared branches), separate installed dependencies (a node_modules or virtualenv isn't part of git and won't exist in the new worktree until you install it there), or separate running services (two worktrees can both try to bind port 3000 just as easily as two directories can). Isolation is at the git level, not the process or filesystem level in general.
Shared-working-tree collisions look like flaky, unreproducible bugs rather than obvious crashes: a test fails because a file was mid-write, a build picks up an import that only exists in the other agent's in-progress change, a commit silently includes changes neither agent intended because git add . swept up both agents' uncommitted work. None of this shows up as an error about "two agents" — it shows up as an error about the code, which is exactly what makes it hard to diagnose after the fact. If you're debugging a collision like this, the interleaving is the actual bug; see the concurrency bug finding guide for the general version of "name the interleaving, don't guess."
| Situation | Worktree? |
|---|---|
| Two agents will edit files that might overlap, even if you don't expect them to | Yes |
| Either agent will run the build, the test suite, or a dev server while the other is active | Yes |
| One agent is exploratory (might get discarded) and you want the option to throw its whole tree away without touching the other's work | Yes |
| A single agent doing strictly sequential steps in one session | No — nothing to isolate from |
| Two agents editing files you're certain are disjoint and neither will build or test | Optional — the risk is low but not zero |
The setup cost is real but small: a fresh worktree usually needs its own dependency install (npm install, a new virtualenv) before anything in it will run, and that cost is paid per worktree, not per task. For a single quick fix, that overhead isn't worth it. For anything where two agents are genuinely concurrent and touching a shared codebase, it's cheaper than debugging a collision that only reproduces intermittently.
git worktree remove ../repo-feature-x after merging, or git worktree prune to clear entries for directories that were deleted manually rather than through remove. A worktree still registered but pointing at a missing directory doesn't break anything immediately, but it will confuse the next git worktree list and is worth cleaning up as routine hygiene rather than letting it accumulate.
This is the same question as picking between a skill, subagent, and slash command or a hook and a skill one level down: figure out what property you actually need — here, isolation from a specific other process — before reaching for the tool that provides it. A worktree is the right tool exactly when the thing you need isolated is "files on disk plus what runs against them," and the wrong tool when what you actually needed was separate dependencies, separate ports, or separate commit history. If the parallel agents in question are also unattended, see running Claude Code headless in CI for the permissions side of that same setup.