Claude Code Rewind, Explained

Claude Code snapshots your files before every prompt you send. When a session goes sideways, /rewind (or a double Esc at an empty prompt) walks you back to any earlier point in that session and lets you restore the code, the conversation, or both. It is a local undo stack that lives beside your git history, not inside it.

The part people learn the hard way: it only covers edits made by Claude's file editing tools. Anything a bash command touched is invisible to it, and so is anything behind a symlink.

The mechanism in one table

What a checkpoint actually is

A checkpoint is not a git commit and it is not a snapshot of your whole repository. It is two things bolted together.

The first half is a position in the conversation. Every prompt you send creates one, which is why the rewind menu reads like a list of your own messages rather than a list of file states.

The second half is a set of pre-edit file copies. Claude Code writes a copy of a file before its editing tools change it, and those copies land in ~/.claude/file-history/<session>/. That ordering matters: the snapshot is the file as it was, not as it became.

The two halves are independent, and that explains a behavior that confuses people the first time they see it. If a checkpoint has no tracked file changes after it, the rewind menu will not offer the code restore options at all. You get the conversation options and nothing else. Nothing is broken. There is simply no file state to put back, because Claude answered a question that turn instead of editing anything.

Checkpoints are saved with the conversation rather than held in memory, so you can quit, come back, run /resume, and still open /rewind on that session's history.

Opening the menu, and the double Esc trap

Two entry points, one of which is booby-trapped.

/rewind always works. Type it, press Enter, the menu opens.

Esc Esc works only when the prompt input is empty. If there is text in the input, double Esc clears the draft instead. The draft is not lost (it goes to your input history, so Up brings it back), but the menu you wanted does not appear. That is the single most common reason someone concludes rewind is broken.

Single Esc is a different key entirely: it interrupts Claude mid-turn, or closes an open dialog such as a permission prompt. Interrupting keeps the work done so far, which means an interrupt does not roll anything back. If you hit Esc to stop a bad edit run, the files Claude already wrote are still written. Rewind is the thing that puts them back.

So the reliable sequence when you have a half-typed prompt sitting there: press Esc Esc once to clear it, press Esc Esc again to open the menu, and press Up afterwards to recover the draft. Or skip the dance and type /rewind.

One version note worth knowing if you are on an older build: before Claude Code v2.1.216, a double Esc at an empty prompt could stop opening the menu for the rest of a long session that used background tasks. On those versions, /rewind is the dependable path.

The six choices in the rewind menu

The menu lists each prompt you sent during the session. You pick a point, then you pick an action.

Restore code and conversation. Both go back to that point. This is the full undo and the one you want after a wrong turn that produced real edits.

Restore conversation. The conversation rewinds to that message; the files on disk stay exactly as they are.

Restore code. File changes revert; the conversation stays intact, including everything Claude learned along the way.

Summarize from here. Compresses the conversation from that point forward into a summary, freeing context window space.

Summarize up to here. Compresses everything before that point, keeping later messages intact.

Never mind. Back to the message list, nothing changed.

The two code options only appear when the selected checkpoint has tracked file changes to revert.

After you restore the conversation, or after you choose Summarize from here, Claude Code puts the original prompt from the selected message back into your input field. That is not a cosmetic touch. It is the intended loop: rewind to the prompt that started the mess, rewrite the prompt so it cannot be misread the same way, send it again.

Code only, conversation only, or both

This is the decision that actually matters, and it comes down to which half of the session went bad.

The interesting case is restoring the conversation alone. It deliberately creates a mismatch: Claude's context describes an earlier version of the repository, while the disk holds the current one. That is useful when you want to re-ask a question against the current state without the previous framing dragging the answer around. It is dangerous the moment you forget you did it, because Claude will reason about files it thinks it knows.

The fix is one sentence in your next prompt. Tell it to re-read the files it is about to touch before proposing anything. A conversation restore is a context reset, not a filesystem read.

Restoring the code alone has the mirror-image use. Claude spent forty minutes learning your schema, your naming conventions, and the three places a change has to land. That knowledge sits in the conversation and costs real tokens to rebuild. Throwing away the files while keeping the reasoning is often the cheapest recovery available.

Summarize is not rewind

The two summarize options share the menu but do something structurally different: they compress context inside the same session, like a targeted /compact aimed at a range you choose.

Summarizing does not change files on disk. The original messages also stay in the session transcript, so the details are still recoverable even though they are no longer occupying the context window. A Summarized conversation marker appears where the compressed messages were.

You can steer the summary. Highlight a Summarize option with the arrow keys and type instructions into the row that reads add context (optional), then press Enter. Selecting the option with its number key instead summarizes immediately with no instructions, which is fine for a verbose debugging stretch and less fine for a design discussion you want preserved in a particular shape.

Summarize keeps you in the same session. If what you actually want is to try a different approach while leaving the original session untouched, that is a different tool: /branch, or claude --continue --fork-session.

Rewinding past a cleared conversation

If you ran /clear earlier in the same Claude Code process, the rewind menu shows an extra entry at the top of the list labelled /resume <session-id> (previous session). Selecting it resumes the conversation that was active before the clear.

That entry sticks around until you exit Claude Code or resume a different session, and it requires v2.1.191 or later. On earlier versions, run /resume and pick the previous session out of the list by hand.

The 100-checkpoint cap and the 30-day clock

Two limits decide how far back you can actually go.

The cap. Claude Code keeps file snapshots for the 100 most recent checkpoints in a session. When an older checkpoint gets discarded, the snapshot files that no remaining checkpoint references are deleted, with one exception: each file's first snapshot is kept, because the VS Code extension uses it as the baseline for its session diffs. Before v2.1.208, superseded snapshot files sat on disk until the session was cleaned up.

Since every prompt creates a checkpoint, 100 checkpoints is 100 prompts. A normal working session never gets near it. A long autonomous loop that fires prompts in a tight cycle burns through it in an afternoon, and the earliest file states are simply gone by the time you notice something went wrong at prompt three.

The clock. Checkpoints are deleted along with their sessions after 30 days. You change that with cleanupPeriodDays in settings, which defaults to 30 and has a minimum of 1. Setting it to 0 fails with a validation error. The cleanup sweep runs at startup, so the deletion happens when you launch Claude Code, not on a background timer.

Both limits point the same direction: checkpoints are for today's mistakes.

Where rewind will not save you

Bash commands are invisible

Checkpointing does not track files modified by bash commands. If Claude runs any of these, the change is outside the system:

rm file.txt
mv old.txt new.txt
cp source.txt dest.txt

Only direct edits made through Claude's file editing tools get snapshotted. This is the sharpest edge in the whole feature, because the operations bash is best at (bulk deletes, renames, moves) are exactly the operations you most want to undo.

Practical consequence: when you ask for a rename or a cleanup, the shape of the request changes the safety of the result. Asking Claude to move a directory of files with mv produces an unrecoverable change. Asking it to edit files through its normal tools produces a recoverable one. When bulk shell work is genuinely the right approach, commit first.

Symlinked and hard-linked paths get skipped

Rewind does not restore through links. When you pick a code restore, Claude Code skips any tracked path that is a symlink or a hard link and reports a partial restore: Restored the code, but skipped N files. The skipped files keep their current contents.

Links are not the only trigger. A path also gets skipped when it is covered by a Read deny rule in your permission settings, because rewind cannot read the backup it would have to write back. Restore that file by hand, or loosen the rule and try again.

The warning itself reports a count. To see the paths, turn on debug logging with /debug before a restore you expect to be messy, and the log at ~/.claude/debug/<session-id>.txt names each skipped path as the restore runs. To find the candidates in advance, list the links in the project with find . -type l for symlinks and find . -type f -links +1 for hard-linked files.

This is not an exotic edge case. Two very common setups trip it: config files that a dotfile manager symlinks into your project, and files that pnpm hard-links into place. If you see a skip you did not expect, inspect the path before trusting its contents, because something replaced that file after the checkpoint was taken.

Before v2.1.216, rewind wrote and deleted straight through links at tracked paths with no warning at all, which is a good reason to be on a current version.

Subagent edits are outside your checkpoints

Edits applied by a subagent land outside your session's checkpoints, so rewinding does not restore them, even though the subagent makes them with the same file editing tools. That includes a background /code-review --fix run and any forked skill running in the background. Git is the recovery path for those.

There is one exception: a skill with context: fork that runs in the foreground edits your working tree during your own turn, so rewind covers its edits normally. As of v2.1.218 a forked skill runs in the background by default, and setting background: false in its frontmatter puts it back in the foreground where the invoking turn waits for the result. Before v2.1.218, forked skills always ran in the foreground.

The mental model: checkpoints belong to a conversation. Work that happens in a different conversation, even one your conversation started, is not yours to rewind.

External and concurrent changes are not captured

Checkpointing only tracks files edited within the current session. Changes you make by hand in your editor, and edits from another Claude Code session running at the same time, are normally not captured. The qualifier matters: they can be captured incidentally, if they happen to touch the same files the current session edits. Do not plan around that.

It is not version control

Checkpoints are session-level recovery. Git is permanent history, collaboration, and anything that has to survive 30 days, a machine, or another person. Treat checkpoints as local undo and commits as the real net. The two do not compete, and the failure mode is treating one as the other.

Working so that rewind can actually save you

Five habits that turn checkpointing from a nice feature into an actual safety net.

Commit before anything wide. Rewind covers a session. A commit covers everything, including the bash deletes and the subagent edits it cannot touch.

Size your prompts to the undo you want. One prompt is one checkpoint. A single prompt containing six loosely related requests is one undo unit, so reverting the sixth thing means reverting all six. Send work in chunks you would be happy to revert whole.

Prefer edit tools over the shell for destructive work. Same outcome, recoverable instead of not.

Turn on /debug before a restore you expect to be partial. It costs nothing and it is the only way to see which paths got skipped.

After a conversation-only restore, make Claude re-read. Its context is now behind the disk. One sentence fixes it.

Turning checkpointing off

The file snapshots are controlled by fileCheckpointingEnabled, which defaults to true and appears in /config as Rewind code (checkpoints). To disable it from settings:

{
  "fileCheckpointingEnabled": false
}

The environment variable CLAUDE_CODE_DISABLE_FILE_CHECKPOINTING does the same thing. That setting governs the file snapshotting, which is the code half of rewind. Most people should leave it on: the snapshots are pre-edit copies of files Claude was going to change anyway, and the cost of having them is far below the cost of one bad refactor you cannot walk back.

Claude Code rewind FAQs

How do I undo what Claude Code just did?

Run /rewind, or press Esc twice at an empty prompt. Choose the prompt you want to return to, then pick Restore code, Restore conversation, or Restore code and conversation. If the code options are missing, that checkpoint has no tracked file changes to revert.

Why does pressing Esc twice not open the rewind menu?

Because the input was not empty. With text in the prompt, double Esc clears the draft instead and saves it to your input history. Press Up to get it back, then press Esc Esc again on the now-empty input.

Does rewind undo files a bash command deleted?

No. Files modified by bash commands are not tracked, so rm, mv, and cp changes cannot be undone through rewind. Only edits made through Claude's file editing tools are snapshotted. Use git.

How many checkpoints does Claude Code keep?

Snapshots for the 100 most recent checkpoints in a session, with one checkpoint per prompt you send. Checkpoints are deleted along with sessions after 30 days by default, which cleanupPeriodDays controls.

Does /rewind still work after I resume a session?

Yes. Checkpoints are saved with the conversation, so resuming a session brings its rewind history back with it, up to the same 100-checkpoint and 30-day limits.

The useful reframe is this: rewind is not an undo button for your repository. It is an undo button for the session, and the session is only one of the things editing your files.

Posted by @speedy_devv