Checkpointing
Claude Code snapshots your files before each prompt you send, so /rewind can restore the code, the conversation, or both to any earlier point in the session.
What it is
Every user prompt creates a checkpoint capturing the state of the files Claude’s editing tools have touched. Claude Code keeps snapshots for the 100 most recent checkpoints in a session and saves them alongside the conversation, so /rewind still works after you resume. Checkpoints are deleted with sessions after 30 days, which you change with cleanupPeriodDays.
Open the menu with /rewind, or by pressing Esc twice when the prompt input is empty. If the input has text, double Esc clears it instead — the cleared text goes to your input history, so Up brings it back. The menu lists every prompt you sent, and selecting one offers: restore code and conversation, restore conversation only, restore code only, summarize from here, summarize up to here, or never mind.
The two code-restore options only appear when the selected checkpoint has tracked file changes. This is the important limitation: only direct edits through Claude’s file editing tools are tracked. Files changed by a Bash command — rm, mv, cp, a codemod script, a formatter run outside a hook — are not captured and cannot be undone this way.
What it does for you
- It makes a wrong turn cheap. Three prompts of a bad approach revert in two keystrokes instead of a manual audit of what changed.
- It separates code from conversation. You can keep the code and rewind the discussion, or keep the discussion and revert the code, depending on which one went wrong.
- It frees context without losing your place. Summarize from here and Summarize up to here compress part of the conversation while leaving files on disk untouched and the original messages in the transcript.
How it works
01A checkpoint is taken before each prompt is processed
Claude Code snapshots the files its editing tools have touched in the session. The 100 most recent checkpoints keep their snapshots; discarding an older one deletes snapshot files no remaining checkpoint references, except each file’s first snapshot.
02The rewind menu lists your prompts
Each row is a message you sent. Selecting one shows the actions available at that point — the code options only when there are tracked changes to revert.
03Restoring code rewrites the tracked files
Files return to their state at that checkpoint. Symlinked and hard-linked paths are skipped with a
Restored the code, but skipped N fileswarning; those keep their current contents.04Restoring the conversation truncates history
The messages after that point are removed and the original prompt is put back in the input field so you can edit and re-send it. Because the remaining history is the same content the cache was built from, the next request hits the earlier cache entry.
05Summarizing compresses without touching disk
Summarize from here compresses everything after the selected message; Summarize up to here compresses everything before it. A Summarized conversation marker appears where the messages were, and the originals stay in the transcript file.
06Subagent edits are usually outside the snapshot
Only a foreground forked skill edits your tree during your own turn and is therefore restorable. Any other subagent’s edits — including a background forked skill and a background
/code-review --fix— need git to revert.
How to implement it
01Commit before anything risky
Checkpoints cover Claude’s file edits within one session. Git covers everything else: Bash-driven changes, subagent edits, and anything older than the session.
02Send the risky instruction as its own prompt
A checkpoint is taken per prompt, so "refactor the auth module" as a standalone message gives you a clean restore point in front of it.
03Open the menu the fast way
Press
Esctwice with an empty input. If you have text in the box, clear it first — the first double-Escclears the input rather than opening the menu.04Pick the narrowest restore that fixes the problem
Restore code only when the conversation is still useful. Restore conversation only when the code is fine but Claude has gone down a reasoning path you want to abandon.
05Use summarize when the problem is context, not correctness
Highlight a Summarize option, type instructions where the row reads add context (optional), and press
Enterto steer what the summary keeps.
Examples
# Before the risky change: a real commit, because checkpoints do not
# cover Bash-driven edits or anything a subagent writes.
git add -A && git commit -m "checkpoint before auth refactor"
# Send the risky instruction as its own prompt so the checkpoint
# sits directly in front of it.
# "Refactor the auth module to use signed JWTs."
# It went wrong three prompts ago:
# press Esc Esc (with an empty input box)
# → select the prompt just before the refactor
# → "Restore code and conversation"
#
# The original prompt comes back in the input field. Edit it and re-send.
# The code is fine but the reasoning went sideways:
# Esc Esc → select → "Restore conversation"
# The session is just too long:
# Esc Esc → highlight "Summarize up to here"
# → type "keep the migration plan and the two failing specs"
# → Enter{
"cleanupPeriodDays": 90
}Use it when
- Undoing a multi-file refactor that went wrong, without reading every diff to work out what changed.
- Trying a second implementation approach from the same starting point after the first one failed.
- Keeping the code Claude wrote while discarding a conversation that has drifted off course.
- Compressing a verbose debugging stretch from its midpoint forward, keeping your initial instructions intact.
- Recovering the conversation that was active before you ran
/clear, from the previous-session entry at the top of the rewind menu.
Avoid it when
- You need durable history. Checkpoints are session-level and expire with the session; git commits are the record you can share, bisect, and revert next month.
- The changes came from Bash.
rm,mv,cp, a codemod, or a script Claude ran are not tracked and rewinding will not bring them back. - A subagent did the work. Rewinding does not restore subagent edits except for a foreground forked skill — use git.
- You want to keep both paths. Rewinding discards the branch you leave behind;
/branchorclaude --continue --fork-sessionpreserves the original session.
Common mistakes
SYMPTOMPressing
Esctwice clears your input instead of opening the rewind menu.FIXDouble
Esconly opens the menu when the input box is empty. Clear it first — the cleared text is saved to input history, soUprecalls it afterwards.SYMPTOMRewinding does not undo the damage because Claude used a shell command.
FIXCheckpointing tracks only Claude’s file editing tools. Anything done through Bash is invisible to it. Commit before letting Claude run destructive commands.
SYMPTOMA restore reports
Restored the code, but skipped N files.FIXSymlinked and hard-linked paths are skipped and keep their current contents. Turn on
/debugbefore restoring to get the skipped paths named in the debug log, then fix those files by hand.SYMPTOMThe code-restore options are missing from the menu.
FIXThey only appear when the selected checkpoint has tracked file changes after it. If Claude only read files and talked, there is nothing to revert.
SYMPTOMTreating checkpoints as a substitute for commits and losing work after 30 days.
FIXCheckpoints are deleted with sessions after
cleanupPeriodDays, which defaults to 30. Commit anything you want to keep.
Best practices
- Commit before any risky instruction; checkpoints complement git, they do not replace it.
- Send risky changes as their own prompt so the checkpoint boundary lands where you want it.
- Restore the narrowest thing that fixes the problem — code, conversation, or both.
- Add focus instructions when summarizing, so the compressed section keeps what you care about.
- Prefer
/rewindover/compactfor abandoning a path: it lands on a prefix that is already cached. - Use
/branchwhen you want to try a different direction and keep the original session intact.
Try it in five minutes
Break something with an edit, then break something with Bash, and see the difference.
- 1.In a scratch git repository, commit a clean state.
- 2.Ask Claude to add a function to a file. Then ask it to rename three things across that file.
- 3.Press
Esctwice with an empty input, select the prompt before the rename, and choose Restore code and conversation. The rename is gone. - 4.Now ask Claude to run
rm <some-file>in Bash. - 5.Rewind again and confirm the file does not come back — Bash-driven changes are not tracked. Recover it with
git checkout -- <file>.
Related concepts
Verified against code.claude.com/docs/en/checkpointing on 2026-08-09. See content/SOURCES.md for the full table.
← / → MOVE BETWEEN CONCEPTS