Why do AI agents end up overwriting each other's changes?

Two agents can each read a file, decide what to change, and save, and neither one checks whether the other already saved first. The second write simply replaces the first on disk, with nothing that flags the loss, so the only symptom is a file that no longer matches what either agent intended.

Does Claude Code's Agent Teams feature stop a file conflict between teammates?

Not on its own. Agent Teams gives a lead session and teammate sessions a shared task list and a way to message each other, but each teammate keeps its own context window, and the documentation does not describe any coordination over which teammate is editing which file. Two teammates assigned overlapping files can still save over each other unless each one works on a separate git worktree.

What happens when multiple agents work in the same checkout?

Either or both of two failures. Two of them can write the same file, with the later save silently replacing the earlier one, or two of them can independently decide to do the same piece of work, finishing it twice with two different results. A shared checkout gives agents no built in way to see each other's edits or claims, so neither failure announces itself.

How do I stop two subagents from editing the same file?

Give each one its own [git worktree](/blog/git-worktrees-explained): a separate working directory on its own branch, so the files one subagent is writing are not even visible to the other. Point each subagent's session at its own worktree path before it starts, and bring the branches back together yourself once each one finishes.

How is a task collision different from a file conflict, and what fixes it?

A file conflict is two agents writing one file. A task collision is two agents claiming one piece of work and both doing it, which wastes a run but corrupts nothing. The fix for a task collision is a shared list that leases a task to one claimant, with the claim expiring on its own if that agent goes quiet, so a second agent sees the row already taken instead of duplicating it.

Guide

When a Lead Agent's Own Helpers Edit the Same File

A lead agent's helpers can overwrite each other's work without either one objecting, and the fix depends on which of two different collisions actually happened.

13 October 2026 · updated 13 October 2026

Quick Answer

Subagents editing the same file happens when a lead agent splits a job across two or more helpers that each hold a stale copy and save over each other without knowing the other exists. That is a different failure from two agents racing to claim the same task off a backlog. A worktree per helper fixes the file collision; a task list that leases work to one claimant fixes the other.

The collision you don't see yourself create

Ask Claude Code to fix every failing test in a module and let it decide how to split the work, and it might send one subagent to fix date parsing and a second to fix timezone handling in the same date utility file, each one starting from a version that existed before the other saved its changes.

Open four terminal tabs yourself and you decided the split, so a collision is at least a surprise you can trace to a choice you made. When a lead agent calls its own helpers mid session, you never see that decision happen; you find out from a file that no longer makes sense, not from a plan you reviewed first.

It is the difference between hiring two contractors yourself and finding out a general contractor subcontracted the same wall to two crews without telling either one the other existed.

A subagent that starts with a fresh, isolated context window has no way of knowing another helper already touched the file it is about to save.
The first sign of this collision is usually a diff that makes no sense, not a warning from either agent.

Subagents editing the same file is a different problem than two agents claiming the same task

Conflict gets used for two failures that have nothing to do with each other. The first is two agents writing the same file: one saves, the other saves over it, and AI agents overwriting each other's changes is exactly what that looks like, a file that silently reverts to a version nobody chose. The second is two agents picking up the same piece of work off a list and each doing the whole task, which corrupts nothing but wastes a run and leaves you reconciling two answers to one bug.

Put multiple agents in the same checkout, whether they are subagents, teammates on an agent team, or helpers in a squad, and you can get either failure, or both.

Treating them as one problem is how people patch the wrong thing. A task list does nothing to stop two agents writing the same file, and a checkout each does nothing to stop two agents claiming the same row.

File collision: one file, two writers, the last save wins, and the first agent's work disappears without a trace.
Task collision: one job, two claimants, both finish it, and you reconcile two different fixes instead of reviewing one.

What the vendors who ship subagents already warn you about

Google's own post announcing subagents in Gemini CLI, before Google retired the tool in June 2026, put the file collision in writing rather than leaving it to be discovered: multiple agents editing code at the same time can lead to conflicts and agents overwriting one another, and parallel subagents also hit usage limits faster since requests go out in parallel.

OpenAI's Codex CLI documentation draws the same line between reading and writing. Codex enables subagent workflows by default through an agents table in its config file, and a subagent can start from a delegation instruction in a project's AGENTS.md file and run several at once. The docs recommend subagents for read heavy work, exploration, tests, triage, to avoid what they name as context pollution and context rot, then warn that parallel write heavy workflows need more care, because agents editing code at once can create conflicts and increase coordination overhead.

Claude Code's own subagents start with, in the docs' words, a fresh, isolated context window, which is why two can disagree about a shared file: neither has seen what the other already did. Agent Teams, Claude Code's experimental feature that is off by default, goes further on the task side, with a lead and teammate sessions sharing one task list, though each teammate keeps its own context window. That is progress on who is claiming what, not a claim that file edits get coordinated too.

Anthropic's own account of building a multi agent research system names the honest boundary behind all three warnings: domains that need shared context between agents are, in its words, not a good fit for splitting across agents at all, and one file two fixes both need to touch is exactly that.

The fix for the file collision: a worktree per helper

A git worktree is a second working directory attached to the same repository, checked out to its own branch, so two of them can never hold the same file open for writing at once. Decide first which helpers write code and which only read it; a helper that is just investigating or running tests does not need one of its own.

From your main checkout, create one worktree per writing helper, naming the path and branch after the work. For the helper fixing date parsing: git worktree add ../fix-date-parsing -b fix-date-parsing. For the one fixing timezone handling: git worktree add ../fix-timezone -b fix-timezone. Point each helper's session at its own path before you give it the task.

Let each helper finish and commit on its own branch, then bring the branches back together yourself with an ordinary merge or rebase, so any real overlap becomes a conflict you resolve on your schedule instead of one that happened silently mid session. When a helper is done, remove its worktree: git worktree remove ../fix-date-parsing.

Only helpers that write code need their own worktree; a read only helper can stay on the shared checkout.
Merge or rebase the branches back together yourself, one at a time, instead of letting two helpers merge mid session.

The fix for the task collision: a task list that leases the work

A worktree never touches the second failure, because two agents each in their own checkout can still both decide to fix the same bug. The fix there is not isolation, it is a shared list that only ever hands a given row to one agent at a time.

Put every piece of work as a row both agents can read, outside either agent's own context window. Before an agent starts a row it claims it, and that claim has to behave like a lease, not a flag only the claimant can clear: it expires on its own if the agent holding it goes quiet, instead of sitting claimed forever because nobody let go.

A closed terminal or a killed process should free the claim immediately. A hang or a stall is the harder case, and that is what a timeout backstop is for: an agent that is alive but stuck still eventually loses the claim so someone else can pick the row back up. Get this right and a second agent sees the row already taken and moves to the next one instead of quietly duplicating it.

A claim should expire on its own, not wait for the claimant to remember to release it.
Closing a pane or killing a process should free a claim at once; a stall needs a timeout as the backstop.

Where Forkbench handles this, and where it still needs you

Forkbench's board gives every task a lease rather than a flag only the claimant can clear: a claim binds to one agent, a closed pane releases it at once, and a 120 second heartbeat backstops an agent that is alive but stuck. A task records no vendor, so any agent on the Thread can claim any task without two landing on the same row.

The file collision takes one click, not zero. A worktree opens from the git panel as its own Thread, so a helper there never touches a sibling's files, but Forkbench does not hand one to every helper automatically. The lead agent, or you, still has to notice which helpers are about to write files and give each one a checkout of its own.

The two mechanisms live in the same product and still do two different jobs: a board with no worktrees stops the task collision and lets the file collision through, and the reverse is just as true.

The board's lease stops two agents taking the same task, with a 120 second heartbeat as the backstop.
A worktree is one click from the git panel and opens as its own Thread.
Forkbench does not create a worktree automatically for each helper; splitting the work so helpers do not share files is still the lead agent's or your call.

When one agent is still the right call

None of this argues for always running more than one agent. Cognition's engineering team made the opposite case directly: a single threaded agent is the safer default, because every action carries an implicit decision, and agents that cannot see each other's context end up making conflicting ones. A file collision and a task collision are both that argument playing out concretely.

The practical test is whether the job actually splits. A tightly coupled change, one function, one migration, one bug with one cause, stays one agent's job, worktree or no worktree, board or no board. Reach for helpers, a worktree each, and a leased task list, once the work genuinely separates into pieces that do not need to see each other to finish.

A single agent cannot collide with itself; that is the strongest argument for keeping some jobs on one.
Split work when the pieces are genuinely independent, not to use more agents for its own sake.

Frequently asked

Why do AI agents end up overwriting each other's changes?
Two agents can each read a file, decide what to change, and save, and neither one checks whether the other already saved first. The second write simply replaces the first on disk, with nothing that flags the loss, so the only symptom is a file that no longer matches what either agent intended.
Does Claude Code's Agent Teams feature stop a file conflict between teammates?
Not on its own. Agent Teams gives a lead session and teammate sessions a shared task list and a way to message each other, but each teammate keeps its own context window, and the documentation does not describe any coordination over which teammate is editing which file. Two teammates assigned overlapping files can still save over each other unless each one works on a separate git worktree.
What happens when multiple agents work in the same checkout?
Either or both of two failures. Two of them can write the same file, with the later save silently replacing the earlier one, or two of them can independently decide to do the same piece of work, finishing it twice with two different results. A shared checkout gives agents no built in way to see each other's edits or claims, so neither failure announces itself.
How do I stop two subagents from editing the same file?
Give each one its own git worktree: a separate working directory on its own branch, so the files one subagent is writing are not even visible to the other. Point each subagent's session at its own worktree path before it starts, and bring the branches back together yourself once each one finishes.
How is a task collision different from a file conflict, and what fixes it?
A file conflict is two agents writing one file. A task collision is two agents claiming one piece of work and both doing it, which wastes a run but corrupts nothing. The fix for a task collision is a shared list that leases a task to one claimant, with the claim expiring on its own if that agent goes quiet, so a second agent sees the row already taken instead of duplicating it.