Parallel Coding Agents with Git Worktrees

Git worktrees are the standard isolation mechanism for running multiple coding agents against one repository: each agent gets its own working directory and its own branch backed by the same underlying repo, so agents cannot see — let alone clobber — each other's uncommitted edits. Conflicts, if any, surface at merge time in normal git tooling, exactly where fifty years of tooling knows how to handle them. This is the documented approach across major harnesses (Anthropic's guidance, Codex's multi-agent worktrees, and most cloud agents replicate it server-side).

When to Use — and When Not To

Parallelize when tasks are independent and file-disjoint: a feature in module A, a test-coverage push in module B, a docs sweep. Do not parallelize tasks that touch the same files — you will pay in merge conflicts what you saved in wall-clock — and don't parallelize before single-agent tasks are reliable (AgenticCodingMaturityModel Level 3 before Level 4): running three agents at a 60% task-success rate just triples your review burden.

Worktree Mechanics

Create one worktree per task, each on a fresh branch, as siblings of the main checkout:

cd ~/src/myrepo
git worktree add ../myrepo-auth-fix    -b agent/auth-fix
git worktree add ../myrepo-search-perf -b agent/search-perf
git worktree list    # main checkout + the two agent trees

Launch one agent per worktree, each started in its own directory with a self-contained brief (a subagent-quality brief — see SubagentOrchestrationPatterns — or a spec file committed on that branch). Terminal multiplexers, tabbed terminals, or harness-native parallel sessions all work; the isolation comes from the filesystem, not the launcher.

After merge, clean up promptly:

git worktree remove ../myrepo-auth-fix
git branch -d agent/auth-fix
git worktree prune   # clears any stale administrative entries

Isolation Beyond Files

The filesystem is isolated; the rest of the machine is not. The classic collisions:

Ports — two agents starting the dev server on the same port; give each worktree distinct port assignments (env var or config) in its brief.
Databases and containers — agents sharing one dev database corrupt each other's test runs; per-worktree database names or per-worktree compose project names.
Build caches and dependency dirs — each worktree needs its own install (node_modules, virtualenv, target/); that's a real disk and setup cost to budget, not a bug. Shared global caches (Maven's ~/.m2, pnpm's store) are usually safe because they're append-only by design; per-project build state is not.

A useful convention: put the isolation assignments (port, DB name, compose project) directly in each agent's brief so the agent enforces them itself.

Merge Discipline

Merge one branch at a time, rebasing or merging the next branch after the previous lands — serial integration of parallel work.
Each branch gets the same gate as human work: tests green, lint clean, review pass (agent or human — see VerificationLoopsForAgenticCoding).
Frequent conflicts are a decomposition smell: if two "independent" tasks keep colliding in the same files, the split was wrong — re-plan the boundaries rather than tolerating conflict resolution as a routine step.

Cleanup Hygiene

Worktree litter is the failure mode nobody warns about: orphaned ../repo-something directories with half-finished branches, months old, confusing every later git worktree list and disk-usage check — and confusing later agents, which may discover and read stale trees. Make cleanup part of the merge ritual, and audit occasionally with git worktree list from the main checkout.