Edit tool silently no-ops (reports success, zero on-disk change) after context compaction — stale file snapshot

Status Open
Reported on v2.1.220
Maintainer reply None cached
Activity 0 comments · opened Jul 27, 2026

Summary

After a long session goes through context compaction, the Edit tool can report success while writing nothing to disk — a silent no-op. The agent believes the edit landed; the file is unchanged.

Environment

  • Claude Code 2.1.220 (also observed on adjacent 2.1.x builds)
  • Linux (WSL2 kernel 6.6.x), local filesystem
  • Long-running session with several background subagents; the affected context had been compacted at least once before the failing edits

What happened

A subagent working on a large Python file (~11k lines) issued two Edit calls. Both returned success. Verifying with Read and wc -l immediately afterwards showed zero on-disk change for both calls. Re-issuing equivalent changes via a shell-based write worked fine. The same session segment later edited a different (smaller, recently-read) file with Edit without any problem.

Suspected mechanism

The failing file had been Read before the conversation was compacted; the failing Edit calls came after compaction. It looks like the Edit tool validated/matched against a stale pre-compaction snapshot of the file and concluded there was nothing to do (or applied against the stale buffer), while still reporting success. Files first read after the compaction were unaffected.

Repro direction (not 100% deterministic)

  1. Start a session and Read a large file.
  2. Drive the session until auto-compaction summarizes the earlier context (or force it).
  3. Edit the file that was read in step 1 (old_string that verifiably exists on disk).
  4. Compare on-disk content before/after — we observed success responses with identical byte content.

Impact

Data-loss class for agent workflows: any pipeline that trusts the Edit success status can silently drop changes late in long sessions. Our workaround was to fall back to shell-based writes and to re-verify on-disk state after edits in post-compaction segments.

Expected

Either the edit is applied, or the tool errors (e.g. "old_string not found" / staleness error) — success with zero change should not be possible.

View original on GitHub ↗