Running Parallel AI Agents Without Merge Conflicts

Git worktrees isolate each agent's files, not the shared runtime, and conflicts move to merge time. How to run parallel coding agents safely.

Git worktrees give each AI coding agent its own checkout, so two agents editing the same repository stop overwriting each other's files mid-task. They do not stop the agents from colliding. Worktrees isolate the codebase, not the runtime, and the conflicts you avoid during editing reappear at merge time. A team running two to four agents at once gets real value from worktrees, then hits a second problem that no amount of filesystem isolation touches.

The scale of that second problem is now measured. A deterministic merge replay across more than 142,000 agent-authored pull requests from over 59,000 repositories found a textual conflict rate of 27.67 percent, with 336,000 conflict regions extracted. A separate study of 33,596 pull requests found that when two agents were active on the same repository at the same time, cross-agent pairs conflicted 41.7 percent of the time, more than double the 19.8 percent for pairs authored by the same agent. The filesystem was never the hard part.

Sources: AgenticFlict: A Large-Scale Dataset of Merge Conflicts in AI Coding Agent Pull Requests on GitHub (arXiv), AI Agent Pull Requests on GitHub: Frequency, Structure, and Merge Conflict Rates (arXiv)

This post argues that the discipline lives at merge time, not in the worktree setup, and that points somewhere commercial: we build TLM Forge, a process layer that gates AI-written changes before they ship. So read the vendor-neutral parts as the load-bearing claims, and read the one product section knowing where it comes from.

What a worktree actually isolates

A git worktree is a second checkout of the same repository, with its own working directory, its own index, and its own HEAD pointing at a separate branch, all sharing one object store. Each agent gets a private filesystem: one session's uncommitted edits are invisible to another until both land as commits. That is the whole mechanism, and it is genuinely useful.

Sources: git-worktree documentation

The major agents now wire this in natively. Claude Code creates and opens an isolated session with a single flag, running claude --worktree feature-auth in one terminal and the same command under a different name in another. Cursor 2.0 runs up to eight agents in parallel on a single prompt, each in its own git worktree, so every agent works on an isolated checkout of the same repo. The OpenAI Codex app ships built-in worktree support so multiple Codex threads work on isolated copies of the same repo. The setup step is close to solved.

Sources: Claude Code: run parallel sessions with worktrees, Cursor 2.0 changelog: run up to eight agents in parallel with worktrees, OpenAI: Introducing the Codex app

What a worktree does not isolate

Everything the code talks to at runtime stays shared. Two agents in separate worktrees still bind to the same port 3000, connect to the same local database, hit the same cache, read the same secrets, and race on the same test fixtures. One agent runs a migration and mutates the schema the other is testing against. One agent's dev server refuses to start because the first already holds the socket. The Augment Code worktree guide states the limit plainly: isolation stops one task from trampling another's files, but does not stop one task's runtime from trampling another's ports, databases, caches, secrets, or test state.

Sources: Augment Code: Git Worktrees for Parallel AI Agent Execution

• Ports: two dev servers both try to bind 3000, and the second one dies on startup.
• Database: a shared local database means one agent's migration or seed rewrites state the other is asserting against.
• Caches and build artifacts: a shared node_modules, target, or build cache lets one agent's install invalidate another's.
• Secrets and env: one .env, one set of API keys, one rate limit that both agents burn through together.
• Test state: shared fixtures, temp files, and ports turn one agent's test run into the other's flaky failure.

Most worktree tutorials stop at the filesystem win and imply the collision problem is solved. It is not solved, it is relocated. Runtime collisions surface as flaky failures that have nothing to do with the feature under test, which is the worst kind of failure because it sends an agent chasing a bug that its own neighbor created.

Conflicts move, they do not vanish

Deferring a conflict to merge time is not the same as preventing it. When edits stay isolated in separate branches, git cannot warn either agent that they are diverging, so the divergence compounds silently until integration. The study of concurrent agent pull requests found that 84.4 percent of conflicted files were source code rather than dependency manifests, and nearly 42 percent of the conflicts were structural, such as add/add or modify/delete, the kind that a three-way merge cannot auto-resolve. These are conflicts a human reads, reasons about, and untangles by hand.

Sources: AI Agent Pull Requests on GitHub: Frequency, Structure, and Merge Conflict Rates (arXiv)

Concurrency is now the default, not the edge case. In the same study, 40.2 percent of repositories contained agent-authored pull requests that were active at the exact same time, and those co-active pairs accounted for 79.4 percent of all agent-generated pull requests. Within a one-week window those figures rose to 53.4 percent and 95.0 percent. If your team runs agents at all, they are already overlapping, and the merge queue is already where the friction lands.

Sources: AI Agent Pull Requests on GitHub: Frequency, Structure, and Merge Conflict Rates (arXiv)

Discipline one: spec-first decomposition

Parallelism is only safe when the tasks are genuinely disjoint, and disjointness is a property of the specification, not the tooling. Before launching agents, write down what each one owns: which modules, which endpoints, which data. If two tasks both need to touch the router, the config, or the same shared model, they are not parallel work wearing two hats, they are one task that will collide at merge no matter how many worktrees you create. The best decomposition splits by feature or domain boundary so that each agent's blast radius sits inside its own directory.

This is where a real spec earns its keep. A task described as "add rate limiting" invites an agent to edit middleware, config, and the auth layer, all shared surfaces. A task scoped as "add a token-bucket limiter in ratelimit/ with this interface, do not modify auth" keeps the agent inside a lane. Writing specs for AI coding agents and how to do agentic coding cover how to draw those boundaries so that two agents own non-overlapping concerns by construction.

Agents also lose the shared context that keeps their work disjoint: the spec, the interface both sides agreed on, the reason a file is off-limits. A private, persistent memory layer such as MemX keeps those decisions durable across sessions, so a second agent starts from what the first one already settled instead of rediscovering it and drifting into the same hotspot.

Discipline two: name the overlap zone

Some files are conflict magnets regardless of how well you decompose, and they should be marked as such up front. Auth logic, database migrations, API contracts, shared config, and dependency manifests are the surfaces where two green branches produce a broken whole. A migration that is valid in isolation can break when a second migration lands with an overlapping ordinal. Two endpoints that each pass their own tests can still ship an incompatible request shape. Green CI on each branch is not evidence that the combination works, because CI never ran the combination.

Overlap-zone review is cheap because the list is short and the diffs against it are rare. Most agent output lands in feature directories and can merge on green. The 10 percent that touches a contract file is where a human read pays for itself, and flagging it by path means you never rely on a reviewer noticing the risk in the moment.

Discipline three: a serialized merge queue

Merge one branch at a time, not all at once. Merging several agent branches simultaneously compounds conflicts, because each merge changes the base the next one has to reconcile against. The reliable pattern is a staging or integration branch: merge branch one, run the full suite plus a behavioral check, merge branch two onto the result, verify again, and only promote to main once the combined state is proven. Serializing turns an N-way conflict into a sequence of two-way ones, which are the conflicts git and a reviewer can actually handle.

Sources: Augment Code: Git Worktrees for Parallel AI Agent Execution

The verification between merges has to be behavioral, not merely a compile and a green suite. After each merge, the question is whether the combined system still does what each spec promised, not whether it builds. This matters most for agent code, because a passing suite is a weaker signal than it looks: agents can write tests shaped to the implementation they already intend to produce, so the tests pass without proving the behavior. Testing AI-generated code covers why a green suite is a starting point for a merge decision rather than the decision itself.

Spec-first decomposition, a named overlap zone, and a serialized merge queue with behavioral verification are the merge discipline that most worktree guides gesture at and stop short of. This is the gap TLM Forge is built for: a spec audit fixes each agent's boundary before any code exists, independent review agents that did not write the diff examine the overlap-zone changes, and an adversarial convergence gate blocks promotion until critical issues reach zero rather than until CI turns green. It does not make merge conflicts disappear. It makes the decision to merge evidence-based instead of color-based.

The boundary on this argument is worth stating. Worktrees are the right foundation, native support in Claude Code, Cursor, and the Codex app is a real improvement, and running agents in parallel is a sound way to move faster. The claim is narrower: filesystem isolation solves the cheapest third of the problem and leaves the runtime and the merge untouched. Teams that pair worktrees with disjoint specs, a marked overlap zone, and a serial merge gate capture the speed without shipping the 27.67 percent.