[Bug] "Unchanged since last read" error when reading file previously accessed in reverted conversation state

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/41542
2. https://github.com/anthropics/claude-code/issues/41667
3. https://github.com/anthropics/claude-code/issues/14002

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

The same "unchanged since last read" Also happens to reads removed by manual compaction.
Haven't tested with automatic compassion.

Adding a related symptom that I think falls under the same root cause:

After a conversation rewind/rollback, Claude is not informed that the filesystem may have diverged from the conversation history. The Read-tool failure ("Unchanged since last read", ENOENT) is one observable symptom, but a more dangerous one is silent: Edit operations.

Scenario

1. Claude edits file foo.cs to add a SQL clause AND ISNULL(r2.NonAttivo, 0) = 0. File on disk is updated.
2. User rolls back the conversation to a point before that edit.
3. Claude's history no longer contains the edit, but the file on disk still does.
4. User asks Claude to make a related change to foo.cs.
5. Claude proceeds based on its (stale) memory of the file. Two failure modes:

• The Edit tool's old_string is exactly what Claude expects, but the file has different content nearby — Claude can produce a syntactically valid but semantically wrong edit.
• Claude tries to re-apply the same clause, duplicating it.

The asymmetry matters: Read failures are loud (the tool returns an error and Claude reacts). Edit failures from this divergence can be silent — the tool reports success, the file changes, and nobody notices until the code misbehaves later.

In my case Claude re-applied the same fix that was already on disk — fortunately the second Edit produced a no-op-like result, but it could just as easily have duplicated the line.

User-side visibility

Beyond Claude's own awareness, the user should also be informed when a rollback leaves files on disk that no longer correspond to anything visible in the current conversation. After rewinding, the user sees a clean history with no trace of the edits that were made — but those edits may still be on disk. This is a silent state divergence that can lead to confusion or data loss regardless of whether Claude later re-reads the files.

A simple notice like "N file(s) modified after this point are still on disk" with the option to revert or inspect them would prevent the user from operating on a misleading mental model.

A concrete cost of this divergence: in my case Claude spent multiple turns investigating and trying to fix a bug that had already been fixed on disk by an edit that the rollback had hidden from the conversation. Time, tokens and user trust are wasted because neither side has any signal that the work is redundant.

Lightweight detection via mtime

A simple defensive check that would catch most of the divergence cases: before any Edit, compare the modification timestamp of the target file against the value recorded at the time of the last Read. If mtime differs, treat the cached state as stale and force a re-read before applying the edit. In the common case (mtime unchanged) the check is essentially free.

This would catch both:

• rollback-induced divergence (the case described above)
• external-editor-induced divergence (user or another process edited the file outside Claude)

I don't have visibility into the current implementation, so I can't say with certainty whether such a check exists today. What I can report is the observable behavior:

• The system clearly tracks something about file state (the "Unchanged since last read" errors in #42264 / #54467 prove it).
• That tracking is tied to internal session state that gets out of sync after a rewind.
• Whatever gate exists is not strong enough to prevent the silent Edit failure described above — in my session, an Edit was applied to content that had already been changed on disk, with no warning.

If a mtime/hash gate is already in place, it may be worth checking whether it's being bypassed or invalidated by the rewind path. If it isn't, adding one would address the symptoms in #42264, #54467, and the silent Edit case in a single change, without requiring a redesign of the rewind machinery.

Suggested fix direction

When a rollback occurs, the system should either:

• (a) Mark all files Claude has touched as "stale", forcing a re-read before the next edit, or
• (b) Surface a system reminder to Claude saying "filesystem state may differ from conversation history; re-read files before editing".

Option (b) is cheaper and would also cover the Read-tool symptoms reported here.

Note that user notification and Claude re-read are complementary, not alternatives. The user notification covers the case where the user picks up work later or hands off to another tool/person; the re-read covers the case where Claude continues working immediately after the rollback.

This is also a session-level concern, not just per-file: even files Claude hasn't read directly may have been edited by the user (or by Claude in the rolled-back portion of the conversation).

I have this problem too, not only on rewinds but if I modify the file in a different session and switch back to the current session to continue. I am frequently having to do work arounds like this:

<img width="484" height="294" alt="Image" src="https://github.com/user-attachments/assets/505220fd-f781-4310-a08b-f04bf5524e8b" />

Note the response: “The read tool’s cache says unchanged”

Any updates on this? Still experiencing this issue on the latest version (2.1.158, Windows)!!

Quick repro on this version:

1. Agent reads a file after the user's message .
2. Run /rewind back to resubmit the message (with modifications, e.g.).
3. Ask agent to read the exact same file.
4. Tool blocks it with "unchanged since last reading," leaving the agent blind to the file in the new context window. Agent starts to make funny moves trying to read the file, thinking it's not readable.

Still happens to me too on Ubuntu. Often.

still happening here after a rewind, I'm on cli version ubuntu, v2.1.160. Workaround for now is agent will usually realize it happened and use cat to read the file instead of the read tool. If necessary you can add a space to the file or something to edit it.

Hitting the same root cause from another angle — no rewind or compaction here. Trigger is just git worktree add.

Scenario:

1. In worktree A I read a global shared file (absolute path, lives outside the repo).
2. git worktree add ../repo-feature B. cwd is now a different worktree with its own git root.
3. Try to read the same file from B. Get back "Wasted call — unchanged since last Read" instead of the body.

Same path, sure, but B is a separate context as far as the workflow goes — separate PreToolUse hook state, separate plan, separate "have I re-anchored here yet". The Read call in B was meant to be exactly that re-anchoring. The hook fires (good) but with no body and no path-discriminating signal that this was a fresh-context read, the agent doesn't know whether the trigger landed where it needed to.

Same shape of pain as the rewind / cross-session reports above: the tracker keys on path only and ignores conversation/session/worktree boundaries.

Aligns with @GitAntNol's mtime/hash idea, but a cheaper variant for this specific case: include cwd (or git rev-parse --show-toplevel) in the dedup key. Crossing into a different worktree would naturally count as a fresh read — same way crossing a rewind boundary should.

Note that /clear hits this too.

On MacOS and version 2.1.187 still this issue is clearly seen and trivially reproduced. Add a file, the harness read it, then rewind back and resend the same message.
@whateverfile
⎿  Read whateverfile (unchanged)

I guess AI is not AIing so much.

UPDATE: Anyway I want to state clearly that this is waste of tokens from the harness. It forces the model to try to use the Read tool again and later to generate another command (like using the Bash tool and cat the file) to finally be able to read the file.

I'm seeing this too, and it probably explains a lot of why people generally despise /compact and auto-compact.
I suspect the fix isn't trivial for /rewind, but for /clear and /compact it should be easy (i.e. clear the read-file index).