Multiple AI Coding Agents in the Same Repo: What Broke

You can run several AI coding agents against the same repository, but not in the same working folder. Give each agent its own git worktree cut from the remote branch, stage files by name, and chain commands so a failed step stops the rest. Without that, agents overwrite each other’s branches, commit to the wrong one and sweep each other’s scratch files into pull requests.

We learned this on our own systems between July and September 2026. Four incidents, one root cause, and a check you can run this week.

What does it look like when two agents share a checkout?

The symptom is a commit that lands somewhere you did not expect. A branch you never touched has your change on it. A pull request carries files you did not write. A diff doubles in size between two looks at it, and nobody edited in between.

All of it comes from one fact. A checkout has one HEAD and one working tree. Every agent or person using that folder is writing to the same two things at the same time, and git gives no warning when the branch under you changes.

What actually happened to us

July 2026: the branch flipped mid-session. A person was working in a long session on a feature branch. Our autonomous builder, a tomte, our word for one production agent with one defined job, checked out its own branch in the same folder. The person’s next commit landed on the builder’s branch, and the push sent an empty branch to the remote. We recovered it from the reflog, but it took longer than the change itself.

August 2026: the base moved, and the clone lied. In one session the main branch advanced several times under us. Work done in a separate worktree absorbed that without trouble. The same session also exposed a shallow clone, where ahead and behind counts came back wrong and a new worktree started from a very old commit. A cheap check caught it, listed below.

September 2026: two sessions inside the same files. A fix landed cleanly in a handful of files. Minutes later the same files showed roughly double the changed lines, because a second live session had built an unrelated feature inside them. Nothing had switched branches. Two sessions were mid-edit in the same tracked files, so a status or diff in the shared folder was a snapshot of someone else’s half-written work.

September 2026, again: the add-everything commit. A small fix went out as a commit several times larger than the change. Running git add -A staged scratch notes from other sessions and two nested worktree folders as embedded repositories. The only warning was one line of git output that scrolled past.

None of these were model errors. Each agent did what it was told. The environment let them step on each other.

Which isolation option fits which job?

The right amount of isolation depends on how much your agents share. Separate worktrees on one machine are the cheapest option that fixes the collisions above. Containers or fresh clones cost more and are worth it when agents also need separate ports, databases or network access.

Setup	What each agent owns	Fixes branch races	Fixes file overlap	Cost
One shared checkout	Nothing	No	No	None, and that is the problem
Branch per agent, one folder	A branch name only	No, HEAD still moves	No	Low
Worktree per agent	Own HEAD, index and files	Yes	Yes	Low, shared object store
Fresh clone or container per agent	Everything, including ports and services	Yes	Yes	Higher: disk, setup time, sync

Branch-per-agent looks like isolation and is not. Two agents can each have “their” branch and still fight over which one the folder has checked out.

Does git worktree actually fix this?

Yes, for the working tree and HEAD. The git documentation says linked worktrees share one repository, including objects and most refs, while each keeps its own HEAD and index. Git also refuses to check out the same branch in two worktrees unless you force it, which turns a silent race into a loud error.

Anthropic’s Claude Code documentation recommends the same pattern for parallel sessions. It describes each worktree as a separate checkout on its own branch, so concurrent edits do not collide. GitHub’s Copilot cloud agent documentation takes the container route: the agent runs in an ephemeral cloud environment, works on one branch at a time and opens one pull request per task. Two vendors, two mechanisms, one conclusion: an agent should never share its working folder.

The caveat is that a worktree isolates files, not meaning. Two agents can still make changes that conflict in logic. That is why the review step matters, and why we wrote separately about AI-written pull requests that pass tests and still have bugs.

The four habits that held

Worktrees are the main fix. These four habits close the gaps they leave.

1. One worktree per agent or session, cut from the remote branch. Create it from the fetched remote reference, not from the current HEAD. In September 2026 we made a worktree from HEAD and it quietly inherited a local commit nobody had pushed. That commit rode along through the fix, the tests and the pull request until a final ancestry check caught it.

2. Chain with &&, never ;. A worktree recipe that uses ; keeps going when a step fails. In one run the worktree creation failed silently, the cd failed, and the remaining commands ran in the shared checkout, including a stray commit on someone else’s branch. With &&, the first failure stops the chain. Start every recipe with a cd that exits on failure, and do not suppress the output of the worktree add.

3. Stage named files, never everything. Use git add path/one path/two, then read git diff --cached --stat before committing. The stat output is the cheapest review you will do all day. If the file count surprises you, stop.

4. Check for other live sessions before taking a shared goal. Worktrees do not stop two agents deciding to fix the same problem. In September 2026 several sessions chased the same backlog problem against the same repository and the same production data. Two of their pull requests edited the same file and one had to be held. Isolation fixes the folder. It does not fix two owners. We now assign one owner per queue and record it somewhere every session reads before starting.

What should you check this week?

Five commands tell you whether your setup is exposed. Run them in any repository your agents touch.

1. git worktree list shows how many working folders exist. One line means every agent shares a folder.
2. git rev-parse --abbrev-ref HEAD run twice, a minute apart, during agent activity. If the answer changes and you did nothing, you have a race.
3. git rev-parse --is-shallow-repository should say false. If it says true, do not trust ahead or behind counts.
4. git status --porcelain at the repository root. Any untracked scratch folder that is not ignored is waiting to be swept into a commit.
5. Open your last three agent pull requests and compare the file count to what the task needed.

Each takes seconds. If two or more come back wrong, fix the isolation before you add another agent.

Where this fits in an AI workforce

Concurrency is where agent fleets stop being a demo. One agent in one folder works on almost any setup. Five agents in one repository need an environment that assumes they will collide, and handles it without anyone watching.

DORA’s 2025 research on AI-assisted software development frames AI as an amplifier of an organisation’s existing strengths and weaknesses. A shared checkout is a weakness, and parallel agents amplify it.

Isolation, fences and a named owner for every queue are part of how we build tomtes in our AI Workforce Sprint. The same discipline runs our own agent fleet, where failures are logged and fixed instead of hidden. Our earlier post on sub-agents that delegate to other sub-agents covers the next layer up, where the coordination problem moves from folders to instructions.

We have not solved every part of this. Two live sessions in one conversation about one goal still depends on people and agents reading the same ledger first. That is a habit, not a lock.

Start async

If you run, or plan to run, more than one coding agent against the same code, send us a note describing your setup. We reply in one business day, no meetings, and tell you which of the collisions above you are exposed to. Start async.