[FEATURE] Rebase pending agent edits onto external file changes instead of invalidating them (merge layer for concurrent human + agent editing)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

In an active session, the file on disk is the only shared state between the human and the agent. Both sides operate read-then-write, with no shared buffer between them — a classic two-writers-with-no-merge-layer setup.

When the file changes underneath a pending agent edit, the change invalidates the agent's view instead of rebasing the pending edit onto the new state. The result is that a logically non-conflicting edit fails: the agent's str_replace/edit either errors out on a stale anchor or has to discard its plan and re-read the file, even though the human's change never touched the region the agent was editing.

This is increasingly common now that the human and the agent routinely edit the same files in the same session, especially through the IDE integration.

Proposed Solution

Feature Description / Proposed Solution

Treat the file as a live representation that both sides mutate and reconcile to disk, i.e. apply collaborative-editing semantics — the CRDT / operational-transform model behind Google Docs — to the agent + human pair rather than to two humans.

The core capability being requested: when the file changes under a pending agent edit, rebase the pending edit onto the new state instead of invalidating the agent's view. Non-overlapping edits merge cleanly; only genuinely overlapping edits surface as conflicts that need a turn.

This request is for the capability, not a specific algorithm. A full CRDT/OT in-memory document is the heavyweight end of the design space; a lighter three-way merge (diff3-style: common ancestor = the agent's last-read state, ours = the agent's pending edit, theirs = the human's on-disk change) would already cover the common non-overlapping case and may be sufficient. Implementation is Anthropic's call — the ask is that an external change no longer auto-fails a disjoint pending edit.

What already exists (partial step)

The IDE integration is already part of the way there. It hands the agent the current selection, the open file, and a "file changed" signal, so there is shared awareness of state. What's missing is the merge: today that "file changed" signal invalidates the agent's view rather than triggering a rebase of the pending edit onto the new bytes. Closing that gap is the whole request.

Current workaround

Manual turn-taking: one writer holds the buffer at a time and explicitly hands it off (human edits → hands to agent → agent edits → hands back). It works precisely because serializing the writers means there's never anything to merge. But it puts the entire coordination burden on the human, serializes work that is often genuinely concurrent, and degrades the moment either side forgets whose turn it is.

Alternative Solutions

• Turn-taking protocol (current workaround): correct, but serializes concurrent work and is manual.
• Locking the file during agent edits: blocks the human from their own editor — wrong direction.
• Three-way / diff3 merge on external change: lighter than full CRDT, likely covers the high-frequency non-overlapping case; a reasonable first increment.

Priority

High - Significant impact on productivity

Feature Category

File operations

Use Case Example

Concurrent refactor while I keep editing by hand.

1. I tell the agent: "Rename validateToken to verifyToken everywhere and update the call sites." It starts working through the codebase while I keep working in my editor.
2. The agent reaches auth.ts, reads it, and queues an edit changing the function definition at lines 40–52.
3. While that edit is still pending, I spot an unrelated bug, add a logger.debug(...) call at line 12, fix an import at line 3, and save. The IDE emits a "file changed" signal.
4. Today: the agent's anchors are now stale. The edit fails, it re-reads the whole file and re-plans, and we're stepping on each other — I effectively have to freeze and stop touching any file it might be mid-edit on.
5. With this feature: the "file changed" signal triggers a rebase. My edits at lines 3 and 12 are disjoint from the agent's edit at lines 40–52, so the pending edit reapplies cleanly against the new buffer. Both changes land, and the agent moves to the next file with no round-trip.
6. Only if I'd edited inside lines 40–52 — the exact region it was mid-edit on — would a real conflict surface, and a single turn resolves it.

This would save time because the human and a long-running agent task (a rename, a codebase-wide migration, a dynamic workflow) could work the same files in parallel, instead of me having to freeze and hand off the buffer every time the agent touches a shared file.

Additional Context

Impact

As human + agent co-editing becomes the default (and the IDE integration actively encourages it), this failure mode scales with usage. A merge layer turns "the human touched the file, the agent has to start over" into "both edits land," removing a recurring class of wasted round-trips, token spend, and occasional clobbered changes — without forcing the human into a manual hand off dance.