Rewind/undo reverts file changes but not conversation context, causing confident-but-stale answers

Summary

When a code change made by Claude is undone (via the rewind/checkpoint feature), the file/code state is reverted, but the conversation context is not. Claude continues to reference the undone implementation as if it still exists — describing it in detail, answering questions about its behavior, and building test artifacts against it — because it is recalling the conversation transcript rather than the current file state.

Steps to reproduce

1. Ask Claude to implement a code change (e.g., add a new function/feature across a couple of files).
2. Use the rewind/undo feature to revert that change on disk (files return to their pre-change state).
3. In the same conversation, ask a follow-up question about the feature that was undone (e.g., "does X behavior happen?", "build a test case for this").

Actual behavior

Claude answers based on its memory of having written the code in the conversation, not on the actual current file contents. It will:

• Describe functions/logic that no longer exist in any file.
• Predict runtime behavior for code that was never actually persisted (post-undo).
• Generate test fixtures or examples targeting the now-reverted feature.

This produces confident, detailed, and entirely incorrect answers, since nothing in the response signals that the underlying implementation is gone.

Expected behavior

At minimum, undoing code changes should not leave the assistant able to assert the reverted code still exists without re-verification. Options that would help:

• Undo could also prune/annotate the corresponding conversation turns so the model doesn't treat undone implementation work as still-current fact.
• Alternatively, some lighter-weight signal (e.g., a system note appended after an undo op: "the following file(s) were reverted: ...") so the model is prompted to re-check state before relying on memory of those edits.

Why this matters

The separation is presumably intentional — letting users discard a bad implementation while keeping the reasoning/discussion that led to it. That's a reasonable goal, but as implemented it creates a sharp edge: the model has no signal that a file it edited earlier in the conversation has since been reverted, so it keeps treating conversation history as ground truth for code state indefinitely. In a long session, this can lead to substantial wasted work (e.g., building test fixtures, writing follow-up explanations, or making further edits on top of an assumption that no longer holds).

Suggested mitigation on the model side (not just the product)

Independent of any product fix, it may be worth having the model default to re-reading a file before making claims about "current" behavior of code it edited earlier in a long session, rather than relying solely on conversation memory — but a product-level signal on undo would close the gap more reliably than relying on the model to always re-verify.