Edit tool's "must Read first" rule conflicts with successful-edit hint, causing repeated stalls
Repro
- Edit a file successfully — the system reminder says
file state is current in your context — no need to Read it back. - Several tool calls later (or even directly after, if state-tracking expired), Edit the same file again → fails with
File has not been read yet. Read it first before writing to it.
Impact
Long agentic sessions stall repeatedly because the model interprets the post-Edit hint as durable ("don't bother re-reading"), but the harness's actual rule is stricter — Read must be the most recent file-touch tool before each Edit. Hitting this on a multi-edit file is jarring: the model appears to "get stuck" mid-task, requiring user intervention to nudge it past the failure.
In a 3+ hour Claude Code session, I observed this same failure mode 6+ times across different files. Each time the user had to interrupt and prompt me to continue, breaking flow.
Asks (in order of preference)
- Make the post-Edit state count as a "read" for subsequent edits so a successful Edit satisfies the requirement for the next one too. This is the cheapest fix and matches what the system reminder already implies.
- Update the system reminder to say
this counts as a read for the NEXT edit only — re-Read before any further editsso the model doesn't generalize incorrectly. - Or: cache file state for N seconds after the last Read/Edit and accept Edits within that window.
Workaround currently in use
Always Read before every Edit, even if the model just edited the file 30 seconds ago. This works but adds 1 round-trip per edit and is easy to forget under sustained agentic load.
Environment
- Claude Code (CLI) running Opus 4.7 (1M context)
- Windows 11, Git Bash shell
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗