Worktrees or clones?
Git worktrees break with multiple autonomous agents because they share the same .git: destructive operations, the branch lock and inherited hooks leak state across tasks. The alternative I run in production: real clones from a local bare mirror — cloning is instant and every task is 100% isolated.
When I shared my autonomous-agent workflow, this was the question that kept coming back: "why real clones instead of git worktrees?". Short version: with one agent, worktrees are fine. With several autonomous agents in parallel, they break — and they break ugly.
The day I understood the problem
I started like everyone: git worktree add per task. Lightweight, fast, no repo duplication. Until I started running several agents at once and got corrupted files and branch cross-oversI couldn't explain. The root cause wasn't an exotic bug: worktrees share the same .git. Anything one agent does to that shared state happens to all of them.
- An agent running
git gc --prune,reset --hard,branch -Dor rewriting history can affect every worktree at once. - Git won't let the same branch be checked out in two worktrees. Sounds minor, but when two autonomous agents decide to work from the same base, the edge cases are nasty: one of them starts from a state it didn't expect.
- Config and hooks are inherited from the parent. An agent that touches
.git/configor installs a hook affects everyone else.
With a single agent none of this hurts: you coordinate. With autonomous agents, nobody coordinates — the structure has to do it.
The way out: real clones from a bare mirror
The obvious objection to clones is cost: cloning a big repo per task is slow. The piece that fixes it is a local bare mirror: clone once from the remote, then every task clones from the mirror — local, instant, no network.
# once per repo: the local mirror
git clone --mirror git@github.com:org/web.git ~/.mirrors/web.git
# per task: a real clone from the mirror (instant)
git clone ~/.mirrors/web.git tasks/checkout-v2/web
cd tasks/checkout-v2/web
git checkout -b checkout-v2 origin/staging
# refresh the mirror when needed
git --git-dir ~/.mirrors/web.git fetch --pruneEvery task ends up 100% isolated: its own files, branches, config and hooks. A blunder only breaks its own task. And since each clone has its own .git, I install a no-push hook against staging/main in each one without polluting the others — the agent works freely on its branch, what matters stays protected.
The thin helper layer
No heavy framework: bash + git. One command (task-new) that in one pass: clones from the mirror, branches from the base, renders the env, assigns a dedicated port block(so two agents never step on each other's ports), installs the hook and creates the E2E reports folder. Teardown (task-rm) aborts if there are uncommitted changes — you never throw work away by accident.
Worktrees vs clones, in one table
| Worktrees | Clones from bare mirror | |
|---|---|---|
| Isolation | Shared .git: gc, reset, branch -D leak across tasks | Total: each task has its own .git |
| Same branch in two tasks | Git forbids it → nasty edge cases between agents | No restriction: every clone is independent |
| Config & hooks | Inherited from parent: one agent affects all | Per-clone (including the no-push hook) |
| Creation cost | Very cheap | Instant when cloning from the local mirror |
| Disk | Minimal | Higher, mitigated by the shared mirror |
| Use it when | Quick fix, single agent, no concurrency | Multiple autonomous agents in parallel |
When worktrees still win
It's not dogma. For a quick fix in a single repo, with one agent (or just you), a worktree is still the right tool: lighter, faster to create, and the cross-contamination risk doesn't exist because there's no concurrency. I keep both: worktrees for one-off fixes, isolated clones for features with agents running in parallel.
FAQ
Why do git worktrees fail with parallel AI agents?
Because every worktree shares the same .git: one agent running gc --prune, reset --hard or branch -D can affect all worktrees; git forbids checking out the same branch in two worktrees; and config and hooks are inherited from the parent. With autonomous agents nobody coordinates that shared state.
Isn't cloning a repo per task slow?
Not if you clone from a local bare mirror: run git clone --mirror once against the remote, then each task clones from the mirror — local, instant, no network.
When are worktrees still the right tool?
For a quick fix in a single repo, with one agent or working alone: they're lighter, faster to create, and without concurrency the cross-contamination risk doesn't exist.
The full pattern — workspaces, ports, the self-correcting E2E loop — is explained interactively at ship.alonsogrimaldo.com.