How to run multiple AI coding agents in parallel without them overwriting each other

To run several AI coding agents at once, give each one its own git worktree, a separate copy of your project on its own branch, and start each agent inside its own copy. Then review every agent’s changes as a diff and merge them one at a time. Once that’s set up, the limit is how fast you can review, not how many agents you can start.

Everything below works with plain git and whichever agent you already use: Claude Code, Codex, Cursor or anything else that runs in a folder. Further down we mention Agency, a free app for this. It’s ours, so weigh that.

Why two agents in one folder break each other

An agent edits the files in the folder you start it in. Start two in the same folder and they share every file, the same branch and the same uncommitted changes.

So one agent rewrites a file while the other is halfway through editing it, and one set of changes quietly disappears. One runs the tests while the other’s half-finished work is on disk, and both read the failures as their own. When they’re done you have one pile of changes and no way to tell who wrote what.

A git worktree fixes this at the source. Git lets one repository have several working folders at once, each checked out on a different branch, all sharing the same history. Each agent gets a folder nobody else is writing to.

What you need

• A project in git. Worktrees have been part of git since version 2.5 (2015), so your copy already has them.
• An agent you can start from a folder: Claude Code, Codex, Cursor, Gemini CLI, OpenCode and so on.
• Two or more tasks that don’t touch the same files. This matters more than any tool.
• Room in your plan. Every agent draws on the same subscription or API limits, so four agents use them up four times as fast.

How to run agents in parallel by hand

Here is the whole process with nothing but git. The examples use a project called myapp and a task that fixes the login page.

1. Split the work into tasks that don’t overlap. “Fix the login redirect” and “add CSV export” can run side by side. “Refactor auth” and “fix the login redirect” can’t, because they’ll edit the same files and you’ll spend the time you saved untangling them.

2. Create a worktree and a branch for each task. Run this from your main project folder. It makes a new folder next to your project, on a new branch called agent/login:

   git worktree add -b agent/login ../myapp-login

   Repeat with a different folder and branch name for every task. git worktree list shows what you have. Keeping them next to the project, not inside it, stops them turning up as stray files in your main copy.

3. Copy in the files git doesn’t track, and install dependencies. A new worktree only contains files that are committed. Your .env with the API keys is almost certainly gitignored, so it isn’t there, and neither is node_modules:

   cp .env ../myapp-login/
   cd ../myapp-login && npm install

   Skip this and the agent hits a missing key, decides the code is broken, and starts “fixing” something that was fine.

4. Give each copy its own port. If your app runs a dev server, every copy will try to start it on the same port, and the second one fails or quietly talks to the first one’s server. Pick a different port per worktree and tell the agent which one is its own:

   npm run dev -- --port 5210

5. Start one agent in each folder, with one task each. One terminal per worktree. Name the task and the boundary in the first message:

   cd ../myapp-login
   claude "Fix the login redirect loop. Only change files under src/auth."

   The same works with codex "..." or any other agent that takes a starting prompt.

6. Review each branch as a diff before you trust it. When an agent says it’s finished, read what it changed against the branch it started from, and run the tests in its folder:

   git diff main...agent/login

   The three dots show only the changes made on agent/login, not everything that has moved on main since. If it’s wrong, tell that agent what’s wrong. Don’t fix it yourself in another copy.

7. Merge one branch at a time, and update the others after each merge. From your main project folder:

   git merge agent/login

   Then, in each worktree still running, bring in what just landed and run the tests again:

   git rebase main

   This is where conflicts show up, if there are any. Better here, one branch at a time, than all at once at the end.

8. Clean up. Once a branch is merged, remove its folder and the branch:

   git worktree remove ../myapp-login
   git branch -d agent/login

That’s it. With two or three agents this is entirely workable by hand. Past three, keeping track of which terminal is which, which branch is reviewed and which ports are taken becomes the job.

What the tools automate

All the main agents now do steps 2 and 3 for you, and some go further. As of October 2026:

Sources: the Claude Code worktree docs, Codex’s worktree docs and Cursor’s worktree docs.

If you live in one of these tools already, use its built-in worktrees. For a Claude Code user running two or three sessions, claude -w plus a .worktreeinclude file covers steps 2, 3 and 8, and the rest is habit. Agency is for running several different agents across several projects, with the review and merge in the same window. It’s free, open source, and runs on macOS and Linux.

The traps nobody mentions

Most guides stop at “use a worktree.” These are the problems we actually hit after that.

Two dev servers on the same port

Every copy of your project thinks it owns port 3000, or whatever your dev server uses. The second one to start either fails, or quietly moves to the next free port and nobody checks which one it got. Then the agent checks its fix in the browser, sees the other copy’s old code, and keeps “fixing”.

The fix is boring: a block of ports per worktree. We built it into Agency on day four, the same day we made it possible to run the app from a workspace at all, because the clash comes with the very first second copy. Each workspace gets a block of ten ports starting at 5200 (5200, 5210, 5220 and so on), handed to everything it runs as AGENCY_PORT. This post was drafted in a workspace that was given 5260. By hand, keep a note of which worktree has which port and put it in the agent’s first message.

The .env file that isn’t there

Worktrees contain committed files and nothing else. Gitignored files, which is exactly where API keys and local config live, are missing in every new copy. The agent doesn’t know it’s missing a file. It sees an error and starts debugging working code.

Copy them in as step 3 above, or let the tool do it. Claude Code and Codex both read a .worktreeinclude file, Cursor runs whatever you put in .cursor/worktrees.json, and Agency started copying root .env files into every new worktree three weeks into the build.

Review becomes the bottleneck

This is the one that changes how you work. Starting agents is nearly free. Reading their work isn’t, and it doesn’t get faster because there’s more of it. Six agents produce six branches. They don’t produce six times your judgement.

Our busiest day building Agency, 3 August 2026, merged 31 agent branches, and each one was read as a diff first. If branches are waiting more than a day for you to read them, you’re running too many.

Merge conflicts move, they don’t vanish

Worktrees stop agents trampling each other while they work. They don’t stop two branches changing the same lines. They move the clash to merge time.

Two habits keep it small. Merge one branch at a time and rebase the rest straight after, so a conflict involves two branches, not five. And hand a conflict back to the agent that wrote the branch, with the conflict in front of it, rather than resolving it yourself. That agent knows what its change was for. Agency has done this since early August: a conflict goes back to the run’s own agent.

What happened when we built a whole app this way

Agency was built by Agency. From the first commit on 18 June 2026 to the beta took 11 weeks: 788 commits, 163 of them merges from agent/* branches cut by the app, against 167 issues in its own markdown tracker. By 6 October that was 1,051 commits, 236 agent branches merged and 243 issues. The case study has the rest.

Those numbers count branches, not quality. Every one of those branches was read as a diff before it merged. That review step is the part of the process that doesn’t parallelise, which is why it got as much of our attention as running the agents did.

Our most expensive wrong turn had nothing to do with git. We first built Agency’s terminal layer on tmux, the standard tool for keeping terminal sessions alive in the background, and spent eight days on bugs that all came from the same design mistake before replacing it. If you’re running agents by hand, tmux or split terminal panes are still a perfectly good way to watch three of them. Why we stopped using tmux for AI coding agents is the full story for anyone building tooling of their own.

When not to run agents in parallel

• When the tasks touch the same files. Run them one after another. Two agents refactoring the same module in parallel cost more to merge than they saved.
• When you can’t review that fast. Unreviewed branches go stale as main moves, and stale branches conflict. Two agents you review the same day beat six you get to on Friday.
• When you don’t know what you want yet. Exploring a problem works better with one agent and you watching and steering. Parallel suits tasks you could describe in a sentence.
• When your plan’s limits are tight. Four agents hit your usage limits four times as fast, and an agent cut off halfway through a task leaves a half-finished branch.

FAQ

Does this work with Codex or Cursor? Yes. Worktrees are a git feature, so any agent that works in a folder works in a worktree. The Codex app and Cursor both create worktrees for you now, as the table above shows.

How many agents is too many? There’s no good published number. A “4–8 worktrees per developer” figure circulates, and we couldn’t find where it comes from. Our rule is as many as you can review the same day. By hand, keeping track gets messy at about three.

What about merge conflicts? Worktrees don’t prevent them, they move them to merge time. Merge one branch at a time, rebase the rest after each merge, and give any conflict back to the agent that wrote the branch.

Is this the same as Claude Code subagents? No. Subagents split one task into parts inside a single session. Worktrees keep separate sessions from touching each other’s files. Claude Code can combine them by giving each subagent its own worktree.

Does every worktree need its own node_modules? Yes, each worktree is a separate folder, so dependencies install separately. Package managers that share one store on disk, like pnpm, make that much cheaper.

That’s the whole process. If you’d rather we just built it for you, that’s what we do. And if you want the review and merge in one window, Agency is free.