You kick off two AI coding agents at once — one refactoring a service file, another adding tests that happen to touch the same directory. Twenty minutes later you check back and one agent’s edits are just gone, quietly clobbered by the other’s save. No error, no warning, just a file that no longer matches what you asked for.
This is not a bug in either agent. Preventing AI agents from overwriting each other’s files comes down to one decision: never let two agents share a working directory. Agents write files the same way you do — by editing what’s on disk — and disk state has no concept of “whose turn it is.” This post covers why collisions happen, the isolation techniques that stop them, and a couple of lighter-weight guardrails worth adding on top.
Why AI Agents Step on Each Other’s Work
An AI coding agent doesn’t know another agent exists unless you tell it. It reads files, reasons about them, and writes changes back — all against whatever state the working directory happens to be in at that moment. If a second process changes the same files in between, the first agent’s next write can silently overwrite that change, or worse, write on top of a half-finished edit and produce a file that satisfies neither task.
This is the same class of problem as a race condition in concurrent programming: two writers, one resource, no coordination. The fix in both cases is identical — give each writer its own copy of the resource, or serialize access to it. For file-editing agents, giving each one its own copy is by far the more practical option, because agents work best with uninterrupted access to a full checkout rather than waiting in a queue.
Give Every Agent Its Own Worktree
The cleanest isolation mechanism already built into git is the worktree. A worktree is a second full checkout of your repository, on its own branch, sharing the same underlying history — so two agents can each have a complete, independent copy of the codebase without cloning it twice.
# Agent A gets its own checkout and branch
git worktree add ../repo-agent-a -b agent/refactor-service
# Agent B gets a separate one, working from the same history
git worktree add ../repo-agent-b -b agent/add-tests
# See every active worktree at a glance
git worktree list
Point each agent at its own directory and neither one can touch the other’s files, even if both are editing something with the same filename. When an agent finishes, you review its branch’s diff and merge it like any other change — no overwrite risk, because the collision never had a chance to happen in the first place.
Branch-Per-Agent, Merge When Ready
Worktrees solve the file-system half of the problem; branches solve the history half. Each agent should also commit to its own branch, never directly to main or to a branch another agent might touch. That way, even if two agents eventually modify the same lines, you resolve it once — as a normal merge conflict at merge time — instead of as a silent overwrite you might not notice for days.
| Setup | Risk of overwrite | Where conflicts surface |
|---|---|---|
| Two agents, one shared directory, one branch | High — silent, invisible | Never — it just happens |
| Two agents, one shared directory, separate branches | Medium — uncommitted work can still collide | At commit time, sometimes too late |
| Two agents, separate worktrees, separate branches | Low — isolated on disk | At merge time, visible and reviewable |
The bottom row is the only setup that turns collisions into something you can see and handle deliberately, rather than something that happens to you.
Other Guardrails: Locks, Scoped Tasks, and Clear Ownership
Isolation is the foundation, but a few smaller habits reduce friction even further:
- Scope tasks narrowly. An agent told to “improve the auth module” has a much smaller blast radius than one told to “clean up the codebase.” Narrow scope means less overlap between what two agents might decide to touch.
- Avoid shared config or lock files across agents when possible. Package manager lock files (
package-lock.json,Cargo.lock) are notorious for generating spurious diffs between branches. Regenerate them at merge time rather than trying to keep them in sync across agents. - Name branches after the task, not the agent.
agent/fix-login-redirecttells you what happened when you look atgit worktree listmonths later;agent-1does not. - Review diffs before merging, every time. Isolation prevents overwrites, but it doesn’t guarantee correctness — a second set of eyes (yours) on the diff catches the cases where two agents made reasonable but incompatible decisions.
Catching Overwrites Early — and Why This Matters More at Scale
Overwrites are dangerous precisely because they’re quiet. There’s no error message when one agent’s write clobbers another’s — the file system just accepts the last write and moves on. A few habits help you catch it before it costs real time: check git status before and after each agent session rather than only at the end of the day, commit early and often within each agent’s own branch so a rollback loses minutes instead of a whole session, and watch for diffs that don’t match the task description — a “add tests” task that also edited a service file deserves a second look even if everything passes.
None of these habits prevent overwrites on their own — that’s still the job of worktrees and branches — but they shorten the gap between “something went wrong” and “I noticed something went wrong,” which matters just as much in practice.
This gets more important, not less, as you scale up. Running one extra agent alongside your own work is a small risk — you notice a stray file change quickly because you’re paying close attention to a single second process. The risk compounds non-linearly as you add more concurrent sessions: two agents sharing a directory have one pair that can collide, five agents sharing a directory have ten possible pairs, and the odds that at least one collision goes unnoticed climb fast. A workflow that’s safe at two agents because you’re being extra careful will not stay safe at five agents unless the underlying setup — one worktree, one branch, per agent — is doing the actual work of preventing collisions. Careful attention is a poor substitute for a system that makes the failure mode structurally impossible.
Getting Started
- The next time you want to run two AI agents on the same repo, create a separate
git worktreefor each one before you start, rather than pointing both at your main checkout. - Give each worktree its own branch, named after the task it’s doing.
- Let each agent finish, then review and merge one branch at a time, resolving any real conflicts explicitly instead of letting one overwrite the other.
- If you’d rather not manage worktrees by hand, download Agents — every session in the sidebar gets its own worktree and branch automatically, with a right-side diff panel so you can see exactly what each agent changed before anything touches your main branch.
Overwrites aren’t a sign you’re running too many agents — they’re a sign the agents don’t have their own space to work in. Give each one an isolated worktree and branch, and running several at once stops being risky and starts being just another Tuesday. The git worktree documentation is worth a skim if you want the full command reference, and Agents bakes this exact pattern in by default.