DEV Community

Cover image for Stop correcting Claude in prose, rewind the session instead
Daniel (San) Ávila
Daniel (San) Ávila

Posted on Originally published at Medium

Stop correcting Claude in prose, rewind the session instead

#ai #devtools #productivity #claude

When Claude makes a change you did not want, the reflex is to type a correction. “You shouldn’t have touched that file, undo it.” That message goes into the context window. Claude’s apology goes into the context window. The re-edit goes into the context window. And the bad version of the file is still sitting in the history, shaping everything that comes after. You paid tokens to make the session worse.

There is a command for exactly this. /rewind moves the session back to an earlier prompt and restores the files Claude edited along the way, so nothing about the mistake survives in the transcript.

What /rewind actually restores

Type /rewind, or press Esc twice while the prompt input is empty, and you get a menu listing every prompt you sent in the session. Pick one and you are offered five actions:

  • Restore code and conversation
  • Restore conversation, which rewinds the transcript and leaves the working tree alone
  • Restore code, which reverts the files and keeps the transcript
  • Summarize from here
  • Summarize up to here

The two code options only show up when that checkpoint has tracked file changes to revert. And if the prompt input has text in it, the first Esc clears the text instead of opening the menu. Press Up afterwards to pull it back out of input history.

What checkpointing does not track

This is the part to internalize before you rely on it. Claude Code snapshots the file edits Claude makes through its own edit tools. That is the entire scope.

Edit / Write by Claude         tracked, /rewind restores it
Bash: rm, mv, cp               not tracked
Your own edits in the editor   not tracked
Background subagents           not tracked
Symlinks and hard links        skipped on restore
Enter fullscreen mode Exit fullscreen mode

The Bash exception is the one that bites. If Claude ran rm old_config.yml as a shell command, /rewind will not bring that file back. Same for mv and cp. Edits from a concurrent session are invisible too, and so are changes made by a background subagent. Foreground forked skills, the ones declared with context: fork and background: false, are the single subagent case that does get restored.

Two more edges. A message you queue while Claude is still working joins the running turn and never gets its own checkpoint, so it will not appear in the menu at all. And restore skips symlinked and hard-linked paths, which is how dotfile managers and pnpm stores end up with “Restored the code, but skipped N files”.

/debug
# then read ~/.claude/debug/<session-id>.txt to see which paths were skipped and why
Enter fullscreen mode Exit fullscreen mode

None of this touches git. Checkpointing is session-level recovery, not version history.

How long a checkpoint lives

A checkpoint is created on every prompt that starts a turn. Claude Code keeps file snapshots for the 100 most recent checkpoints in a session, and a session’s snapshots are swept roughly 30 days after it last saved one. That window is cleanupPeriodDays in settings.json.

{
  "cleanupPeriodDays": 90,
  "fileCheckpointingEnabled": true
}
Enter fullscreen mode Exit fullscreen mode

Rewinding to a checkpoint whose snapshots were already swept fails with No files were restored. If you keep long-lived sessions around, raise the number before you need it, not after.

Checkpoints are saved with the conversation, so resuming a session days later still gives you the full rewind menu. If you ran /clear earlier in the same process, the menu puts a /resume <session-id> (previous session) entry at the top so you can rewind past the clear. That entry needs v2.1.191 or later.

To turn file snapshots off entirely, set fileCheckpointingEnabled to false, or export CLAUDE_CODE_DISABLE_CHECKPOINTS with any non-empty value.

It is not /clear, /compact or /branch

These get mixed up constantly. Only one of them writes to your working tree.

  • /rewind restores files and transcript to an earlier point. The only one that puts files back.
  • /clear starts an empty context and saves the old conversation so you can resume it. Files untouched.
  • /compact replaces the transcript with a summary in place, same session. Files untouched.
  • /resume, --resume and --continue load an existing session from disk. Files untouched.
  • /branch and --fork-session copy the conversation up to now into a new session. Files untouched.

So when a change goes wrong, /compact does nothing for you, and /clear throws the good context away along with the bad. Rewind is the surgical one.

The order to do it in

  1. Notice the bad change before you start typing a correction.
  2. Clear the prompt input, then press Esc twice.
  3. Pick the prompt that came immediately before the mistake.
  4. Choose Restore code and conversation if Claude’s edits caused it, or Restore conversation if you only want the transcript cleaned up.
  5. Run git status and check for anything Bash or a background subagent did, because rewind did not touch those.
  6. Rewrite the prompt with the guardrail that was missing, and send it again.

You can follow me on my social media:

Top comments (0)