15 / 20Workflow6 MIN READ

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.

Scrubbing a session timeline back to an earlier checkpointA horizontal timeline of checkpoints, one per prompt. A playhead moves back from the end to the third checkpoint, dimming the checkpoints after it to show the state being restored.SESSION TIMELINErestore code + conversationbash editsnot tracked

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

  1. 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.

  2. 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.

  3. 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 files warning; those keep their current contents.

  4. 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.

  5. 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.

  6. 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

  1. 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.

  2. 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.

  3. 03Open the menu the fast way

    Press Esc twice with an empty input. If you have text in the box, clear it first — the first double-Esc clears the input rather than opening the menu.

  4. 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.

  5. 05Use summarize when the problem is context, not correctness

    Highlight a Summarize option, type instructions where the row reads add context (optional), and press Enter to steer what the summary keeps.

Examples

Recovering from a bad refactorbash
# 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
Git for the durable boundary, checkpoints for the fast one inside the session.
.claude/settings.jsonjson
{
  "cleanupPeriodDays": 90
}
Checkpoints are deleted with sessions after 30 days. This keeps them for a quarter.

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; /branch or claude --continue --fork-session preserves the original session.

Common mistakes

  • SYMPTOMPressing Esc twice clears your input instead of opening the rewind menu.

    FIXDouble Esc only opens the menu when the input box is empty. Clear it first — the cleared text is saved to input history, so Up recalls 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 /debug before 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 /rewind over /compact for abandoning a path: it lands on a prefix that is already cached.
  • Use /branch when 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. 1.In a scratch git repository, commit a clean state.
  2. 2.Ask Claude to add a function to a file. Then ask it to rename three things across that file.
  3. 3.Press Esc twice with an empty input, select the prompt before the rename, and choose Restore code and conversation. The rename is gone.
  4. 4.Now ask Claude to run rm <some-file> in Bash.
  5. 5.Rewind again and confirm the file does not come back — Bash-driven changes are not tracked. Recover it with git checkout -- <file>.

Verified against code.claude.com/docs/en/checkpointing on 2026-08-09. See content/SOURCES.md for the full table.

← / → MOVE BETWEEN CONCEPTS