claude-code - 💡(How to fix) Fix [Bug] Read tool cache survives esc-esc rewind, returning "unchanged" stubs without content [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#55042Fetched 2026-05-01 05:47:45
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Timeline (top)
labeled ×5commented ×1

Root Cause

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.

Fix Action

Fix / Workaround

Workarounds that bypassed the cache

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

Code Example

[]
RAW_BUFFERClick to expand / collapse

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

[]

extent analysis

TL;DR

The issue can be mitigated by using the limit parameter with the Read tool to force a fresh read instead of relying on the cache.

Guidance

  • The cache state not being properly reset after an esc-esc rewind is the likely cause of the issue, leading to the "File unchanged since last read" stub being returned without actual content.
  • To verify if the cache is the cause, try using the Read tool with a limit parameter, as mentioned in the workarounds, to see if it forces a fresh read.
  • Another way to mitigate the issue is to use an independent method to confirm file existence and sizes, such as the Bash wc -l command, to ensure the assistant is not providing fabricated answers.
  • When re-issuing Read on the same files after an esc-esc rewind, check if the tool returns the actual content instead of the "unchanged" stub to confirm if the cache has been properly reset.

Example

No code snippet is provided as the issue does not explicitly mention any specific code that needs to be modified.

Notes

The provided workarounds suggest that the issue is related to the cache not being properly reset after an esc-esc rewind. However, the root cause of this behavior is not explicitly stated, and the provided Errors section is empty, which might indicate that the issue is not related to any specific error but rather to the logic of the cache management.

Recommendation

Apply workaround: Using the limit parameter with the Read tool is a reliable method to force a fresh read and mitigate the issue of silent context loss. This approach ensures that the assistant provides accurate information by re-reading the files instead of relying on potentially outdated cache content.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [Bug] Read tool cache survives esc-esc rewind, returning "unchanged" stubs without content [1 comments, 2 participants]