[Bug] Read tool cache survives esc-esc rewind, returning "unchanged" stubs without content

Bug Description

After an esc-esc rewind, the Read tool reports files as already-read and returns a "File unchanged since last read" stub instead of the file contents — but the assistant no longer has those contents in its visible context, because the prior tool_results were in the rewound turn that was supposed to be discarded. The cache state outlived the transcript state it was supposed to mirror.

User Perspective

I sent an initial message that caused Claude to read a bunch of files I didn't think were relevant. I used esc-esc to rewind and edited my first message to narrow the scope of what should be read. From my side everything looked normal — Claude responded and started working — but Claude flagged mid-response that the Read tool was claiming files were already cached while it actually had no visible content for them. If Claude hadn't caught and reported this, I'd have no way to know from the UI that it was answering about documents it had never actually seen. The risk is silent context loss leading to confident hallucinations on rewound sessions.

Claude's Perspective

Called Read on five files in parallel after the rewind. Four returned this exact string with no payload:

File unchanged since last read. The content from the earlier Read tool_result in this conversation is still current — refer to that instead of re-reading.

Only one file returned actual content (the one read post-rewind, not by the discarded fork). The four cached-stub responses were suspicious only because they arrived in a row — a single isolated cache-hit on one file would likely have slipped past unnoticed and led to fabricated answers. The tool's truthfulness contract ("refer to that instead") is broken when the referenced tool_result no longer exists in the transcript.

Workarounds that bypassed the cache

• Read with a limit parameter forced a fresh read
• Bash wc -l confirmed file existence and sizes independently

Reproduction

1. Issue several Read calls in a turn
2. esc-esc rewind to before those Reads
3. Edit the prior message and resend
4. Re-issue Read on the same files → returns the "unchanged" stub with no content

Severity: High — silent context loss is the worst failure mode for an assistant. Caught here only by luck (four-in-a-row pattern was conspicuous).

Environment Info

• Platform: win32
• Terminal: windows-terminal
• Version: 2.1.123
• Feedback ID: c5768dbd-80eb-42d3-a6ae-181250aa84d1

Errors

[]