Two AI Agents Edited the Same File: Clean Merge

Q: Are these real git conflicts or something else?

Usually not. Only Cause 3 (two branches merging) produces `<<<<<<<` markers. Causes 1, 2, 4, and 5 are silent overwrites: the file is simply wrong, with no markers, because one agent's write replaced another's. That's why the first thing to check is whether `git grep` finds any markers at all.

Q: Should I just let the AI resolve the conflict for me?

For a true merge conflict with markers, an agent can often resolve it, but review every line, because it will happily pick a side that drops behavior the other side needed. For silent overwrites (no markers), there's nothing for the agent to "resolve"; you have to recover both intent versions yourself, as in Steps 2 to 4.

Q: Can two agents safely edit the same file if I'm careful?

No reliable way. There are no file locks between Cursor, Claude Code, and Aider, so it always comes down to last-write-wins. Either give them separate files/directories, or separate worktrees. If a single file genuinely needs both, run the agents one after the other and commit in between.

Q: Cursor 3 uses worktrees automatically — why do I still get conflicts?

Worktree isolation only applies to agents you launch into a worktree (the Agents Window, or `/worktree`). If you edit the same file in your own main checkout while an agent runs there, or you're on an older Cursor build, you're back to one shared tree and last-write-wins.

Q: How do I avoid losing work mid-merge?

Snapshot before you touch anything: `git stash push -u -m backup` or `git branch backup/conflict-snapshot-$(date +%s)`. Then extract each agent's full file into `/tmp` before editing the working copy. With the snapshot and the temp files, no path through the merge can lose data permanently.

Cursor and Claude Code clobbered the same file. Stop both, recover each intent, merge by hunk, and isolate agents with worktrees so it never repeats.

Published: May 17, 2026 Updated: Jun 21, 2026 Author: AI Productivity Guide Team 🌐 查看中文版本

You ask Cursor to edit Header.tsx while a Claude Code session in a separate terminal is editing the same file; or you have a Cursor background agent plus the main chat running together; or two teammates fire up agents on the same code. The result: files clobbered, git status showing half-baked content that’s neither yours nor either agent’s complete intent. Cursor, Claude Code, and Aider don’t share file locks — each one reads, thinks, and writes against the snapshot it saw, and the last write wins.

Fastest fix: stop every agent now (don’t keep typing), git stash a backup, pull each agent’s version into its own temp file, pick one as the base, and port the other side’s good hunks in by hand. Then stop this happening again by giving each agent its own git worktree — both Cursor 3 and Claude Code create these automatically (the /worktree command in Cursor’s Agents Window, or claude -w in the CLI). The full flow is below.

Which bucket are you in

Match the symptom to the cause before you touch anything. This decides whether you have a true git conflict (with <<<<<<< markers) or a silent overwrite (no markers, just wrong content).

Symptom you see	Most likely cause	Go to
File mixes two naming/comment styles, no conflict markers	Two agents wrote the same file, last write won	Cause 1
Cursor: “patch could not be applied cleanly” / “file modified externally”	Background agent’s patch built against a stale version	Cause 2
`git merge` shows `<<<<<<<` markers, both sides look machine-written	Two people, two branches, two agents	Cause 3
IDE pops “reload from disk?” on a file you didn’t touch	Auto-apply / watch wrote silently	Cause 4
No markers, but the refactor fights itself (switch vs ternary)	Different models pulled in opposite directions	Cause 5

Common causes

Ordered by hit rate, highest first.

1. Two agents on the same workspace at once

The classic case: Cursor’s Chat / Composer plus Claude Code CLI in the same directory. Both “read → think → write” without coordinating.

How to spot it: git status shows a file that isn’t what you just typed and isn’t a clean output from either agent; the file mixes two different naming styles or comment voices.

2. Cursor background agent + foreground chat together

A Cursor agent runs a task while you edit the same file in the foreground. When the task finishes, the disk has moved on, but its patch was built against the older version — apply fails or produces misaligned hunks. As of June 2026, Cursor 3 (shipped April 2, 2026) runs agents in isolated git worktrees by default when you launch them from the Agents Window, which sidesteps this — but it still bites you when an agent and your own editor share the same checkout (the classic single-tree setup, or an older Cursor build).

How to spot it: Cursor reports “patch could not be applied cleanly” or “file has been modified externally.”

3. Multiple humans, each running their own agent on the same repo

Two devs on separate branches both use agents on the same module. At merge time the conflict markers look like two “AI styles” arguing.

How to spot it: git merge conflicts where neither side reads like a human wrote it, but each is “plausible yet structurally incompatible.”

4. Watch / autopilot triggers silent writes

Some agents write to disk without an explicit confirmation: Cursor’s Auto-Apply, or Aider, which auto-commits every edit by default (auto-commit is on unless you pass --no-auto-commits). You’re editing Header.tsx, the agent quietly edits it too, the IDE asks “file modified externally, reload?”

How to spot it: IDE prompts a “reload from disk” dialog for a file you didn’t touch in another window.

5. Different-model “style conflict”

GPT leans functional, Claude leans imperative-and-chunked. Two agents working the same module pull the refactor in opposite directions. Even without raw conflicts, the merged code is a “two-philosophies stitched together” mess.

How to spot it: git log -p on the two commits shows one converting if/else to switch, the other converting the same switch back to ternary.

Shortest path to fix

Step 1: Stop everything

Kill every running agent — quit Cursor (or at least close Composer / Background Agent), terminate the Claude Code CLI, kill autopilot / watch processes. Continuing to type only stacks more race conditions on top.

# Find suspect agent processes
ps aux | grep -E '(cursor|claude|aider|cline)' | grep -v grep

# Kill if needed
pkill -f "claude-code"
pkill -f "aider"

Wait until disk state stays still for 30 seconds before the next step.

Step 2: Snapshot everything, then read git status

So the merge below doesn’t lose anything else:

git stash push -u -m "multi-agent-mess-$(date +%s)"
# or
git branch backup/conflict-snapshot-$(date +%s)
git stash pop  # restore changes to working tree

Then see who touched what:

git status
git diff
git log --all --oneline -10

Step 3: Extract each agent’s “intent version” as a full file

Pull both sides into separate files for clean comparison:

# Assume Cursor already committed
git show <cursor-commit-sha>:src/Header.tsx > /tmp/cursor-version.tsx

# Claude Code's edits are still in the working tree
cp src/Header.tsx /tmp/claude-version.tsx

# Get the original (pre-agent) version
git show HEAD~2:src/Header.tsx > /tmp/original.tsx

Open all three in a 3-way diff:

code --diff /tmp/cursor-version.tsx /tmp/claude-version.tsx
# or
diff3 /tmp/cursor-version.tsx /tmp/original.tsx /tmp/claude-version.tsx

Step 4: Pick a source of truth, port the other side hunk-by-hunk

Choose the version with the clearer, broader intent as the base, then overlay the other side’s useful hunks:

# Write the base back to the working tree
cp /tmp/cursor-version.tsx src/Header.tsx

# Use add -p to interactively pick Claude's hunks
git diff --no-index src/Header.tsx /tmp/claude-version.tsx | less
# Manually copy the hunks you want into src/Header.tsx

More visually, use Cursor / VS Code’s “Source Control” panel: click ”+” on each hunk to stage what you want, skip conflict artifacts. When both sides touched the same line, the base version wins — don’t try to “blend” them. Blending introduces behavior neither side ever tested.

Step 5: Land it with a precise commit message

git add src/Header.tsx
git commit -m "merge: resolve cursor+claude divergence on Header.tsx

- kept cursor's restructuring of nav menu
- ported claude's a11y label fixes (lines 42-58)
- discarded both agents' duplicate handleClick implementations
- next: single agent per overlap file"

Spell out what stayed, what was dropped, and why. The next time something breaks, git log answers it directly.

How to confirm it’s actually fixed

Don’t trust the eyeball merge. Run these before moving on:

# 1. No conflict markers left anywhere
git grep -nE '^(<<<<<<<|=======|>>>>>>>)' && echo "MARKERS STILL PRESENT" || echo "clean"

# 2. The file still parses / type-checks / builds
npm run typecheck   # or: tsc --noEmit, eslint src/Header.tsx

# 3. The behavior both agents cared about still works
npm test -- Header

If step 1 prints clean, step 2 passes, and the relevant tests are green, the merge held. If a test that passed before now fails, you dropped a hunk one side needed — go back to /tmp/cursor-version.tsx and /tmp/claude-version.tsx and find it.

Step 6: Enforce “one agent per overlap” going forward

Only one agent on a given file at a time. The simplest enforcement:

# Tool A: you, foreground Cursor — owns src/components/
# Tool B: Claude Code, background — owns scripts/, tests/, docs/

# Write it down in CLAUDE.md
echo "Owned by Cursor: src/components/, src/pages/" >> CLAUDE.md
echo "Owned by Claude Code: scripts/, tests/, docs/" >> CLAUDE.md

Or temporarily hide the other agent’s directories from Cursor via .cursorignore. Note the distinction: .cursorignore blocks the agent from reading or editing those paths at all, while .cursorindexingignore only keeps them out of the search index (the agent can still open them when you @-mention them). For “this agent must not touch these files,” use .cursorignore.

Prevention: isolate agents instead of policing them

The real fix is structural — stop two agents from ever sharing one checkout. As of June 2026 both major tools build the isolation for you, so you rarely need the manual ownership hacks anymore.

Give each agent its own git worktree (the durable fix)

A worktree is a second checkout of the same repo in a different folder, on a different branch, sharing one .git object store. Two agents in two worktrees physically cannot clobber each other’s files.

# Manual, works with any tool
git worktree add ../proj-claude -b feature-claude
git worktree add ../proj-cursor -b feature-cursor
# point each agent at its own folder; merge the branches when both finish
git worktree remove ../proj-claude   # clean up when done

Cursor 3 (Agents Window): launch agents from the Agents Window and they each get an isolated worktree automatically, or type /worktree in the Editor Window to run the current task in one. A machine-wide cap of 25 worktrees is set by cursor.worktreeMaxCount. Up to 8 agents can run in parallel.
Claude Code: start a session in its own worktree with claude -w, or tell Claude “use worktrees for your agents” so subagents stay isolated (set it permanently on a custom subagent with isolation: worktree in its frontmatter). Add .claude/worktrees/ to .gitignore — that metadata is per-machine, not shared.

Most people find 2 to 4 parallel agents manageable; past 4 to 5 on one laptop, reviewing and merging the outputs costs more than the parallelism saves.

When you can’t use worktrees

One coding agent per checkout at a time. If two must share a tree, give each an explicit, non-overlapping directory it owns.
Document directory ownership in CLAUDE.md / .cursorrules / AGENTS.md, e.g. src/api/ is Cursor’s, scripts/ is Claude Code’s.
Commit the moment an agent finishes a task, before switching to the next agent — the commit is the handoff signal and the rollback point.
Turn off silent writes: disable Cursor’s Auto-Apply, and run Aider with --no-auto-commits so each edit needs your confirmation.
In team PRs, note which files each agent touched so reviewers and future merges know.

FAQ

Are these real git conflicts or something else? Usually not. Only Cause 3 (two branches merging) produces <<<<<<< markers. Causes 1, 2, 4, and 5 are silent overwrites: the file is simply wrong, with no markers, because one agent’s write replaced another’s. That’s why the first thing to check is whether git grep finds any markers at all.

Should I just let the AI resolve the conflict for me? For a true merge conflict with markers, an agent can often resolve it, but review every line, because it will happily pick a side that drops behavior the other side needed. For silent overwrites (no markers), there’s nothing for the agent to “resolve”; you have to recover both intent versions yourself, as in Steps 2 to 4.

Can two agents safely edit the same file if I’m careful? No reliable way. There are no file locks between Cursor, Claude Code, and Aider, so it always comes down to last-write-wins. Either give them separate files/directories, or separate worktrees. If a single file genuinely needs both, run the agents one after the other and commit in between.

Cursor 3 uses worktrees automatically — why do I still get conflicts? Worktree isolation only applies to agents you launch into a worktree (the Agents Window, or /worktree). If you edit the same file in your own main checkout while an agent runs there, or you’re on an older Cursor build, you’re back to one shared tree and last-write-wins.

How do I avoid losing work mid-merge? Snapshot before you touch anything: git stash push -u -m backup or git branch backup/conflict-snapshot-$(date +%s). Then extract each agent’s full file into /tmp before editing the working copy. With the snapshot and the temp files, no path through the merge can lose data permanently.

Tags: #AI coding #Debug #Troubleshooting