How to run several coding agents on one repo without collisions
Coding agents are fast enough now that the bottleneck is you. One agent at a time means you watch it work; three at a time means you review while they work. The catch is that three agents in one folder destroy each other's changes. This post is the setup we use to avoid that, with the Git underneath it, and the review habit that keeps the result trustworthy.
Why agents collide
An agent such as Claude Code or Codex works the way a person does: it reads files in a folder, edits them and runs commands there. Two agents in the same folder see each other's half-finished edits, build on them, and overwrite them. Tests one agent runs pick up the other's broken state. Git makes it worse, not better, because both agents commit to the same branch and HEAD becomes a braid of two unrelated tasks.
The fix is the same one you would use for two people: separate folders and separate branches. Git has a primitive for exactly this, the worktree, and it has had it since 2015. A worktree is a second working folder of the same repository, with its own checked-out branch, its own index and its own files, sharing the object store and the branch list with the main folder. The post on worktrees, stash and clones explains the trade-offs; the short version is that a worktree is cheap, instant, and still the same repository, so you can diff and merge between agents' branches without pushing anything anywhere.
The setup
One worktree per agent, one branch per task. Before you start an agent, create a worktree on a new branch named for the task:
git worktree add ../api.worktrees/agent-search-index -b agent/search-indexThen start the agent in that folder and give it the task. It can only see that folder and only commit to that branch. Start the next agent in the next worktree. Six at once is fine; the repository does not care.
Make the folder runnable. A new worktree has the branch's tracked files and nothing else: no .env, no node_modules, no build. An agent dropped into that folder spends its first ten minutes rediscovering how to install the project, or worse, invents a .env. Copy or link those files before the agent starts. Mergepond does this with a setup recipe that runs every time a worktree is created: copy .env, link node_modules, run pnpm install. By hand, a small shell script does the same.
Tell the agent the rules. In the prompt or the project's instructions file, say three things: commit as you go with clear messages, never switch branches or create worktrees, and stop when the task is done rather than wandering into the next one. Agents follow these reliably; the collisions you are left with are the real ones, where two tasks genuinely touch the same code.
Keep your own worktree. Do not run agents in the main folder you work in. Leave it on your branch, so you can keep making your own changes and so a git status there always tells you about your work, not theirs.
Watching them
With six folders, the question becomes which agent needs you. The answer is in Git already: a worktree with uncommitted changes is still working; one whose branch is ahead of main with a clean tree has finished and needs review; one whose branch has merged is done and can be deleted.
git worktree list and a loop over git status --porcelain and git rev-list --count will tell you that. We wanted it on screen without the loop, so Mergepond's Worktrees view draws every worktree as a card and sorts them into three columns, Working, Ready for review, and Merged or gone, updating as the agents save and commit. A card reads "4 changed files" while the agent is typing, "3 commits to push" or "Ready for review" when it has stopped, and "Safe to remove" with the disk it frees once the branch has merged. The guide to running agents in parallel walks through the view.
Whatever you use to watch, the rule is the same: an agent's output is a branch, and the branch's state tells you what to do next.
Reviewing
This is the step that makes the whole thing safe, and it is the step people skip when they are excited.
Open the agent's branch in your Git client and read its commits as you would a colleague's pull request. Read the diff, not the agent's summary of the diff. Run the tests in the agent's worktree, where its dependencies are. If the branch is wrong, tell the agent so in the same worktree and let it iterate; the branch keeps the history of the attempts, which is useful later. If the commits are messy, interactive rebase the branch into a shape you would sign your name to before it reaches main.
Then merge it into your branch, from your worktree. Two agents that touched the same lines will conflict here, and here is the right place to resolve it: you can see both intentions, and neither agent is still editing. Resolving the conflict by asking one agent to "rebase onto the other's work" means an agent making a judgement about a change it did not make. Do it yourself.
Push, delete the worktree, keep or delete the branch. The whole cycle for one task is: create, start, watch, review, merge, remove.
What goes wrong
An agent switches branches anyway. Git will refuse if the branch is checked out elsewhere, which usually stops it. If an agent does end up on the wrong branch, its commits are still there; cherry-pick them to the right one and reset the wrong one.
Two agents install different dependency versions. If you link node_modules between worktrees, one agent's pnpm add changes the shared folder for all of them. Either accept that and keep the lockfile honest at review time, or give each worktree its own install and pay the disk.
A port or a database is shared. Dev servers default to the same port; two agents' test runs hit the same local database. Parameterise those by folder name in your scripts, or run one integration task at a time and let the rest be unit work.
You forget which card was which. Name branches for the task, agent/search-index, not for the agent, agent/claude-3. The folder pattern turns the slash into a dash, and a week later the name still means something.
You stop reviewing. The agents are good, the tests pass, and merging the fifth branch of the day without reading it feels fine. It is fine until the one that quietly changed an auth check. The review is the product; the agents are the draft.
Where this is going
Agents and worktrees fit together well enough that the tooling around them should get smaller, not bigger. The Git side is already solved; what is left is making a worktree as cheap to think about as a tab in your editor, and making the state of six of them visible at a glance. That is the part of Mergepond we spend most of our time on, and the part we expect to change most over the coming year. If you run agents this way and something in the cycle above still has friction, write to us; the specific case is what we want to hear.