Beginner7 min

Checkpoints: Claude Code's Built-In Undo System

Claude Code automatically creates a checkpoint for every user prompt — a snapshot you can rewind to at any time. This article explains what checkpoints track, what they miss, your five restore options, and how checkpoints relate to git.

Quick Reference

  • A checkpoint is created for every user message — not per file edit
  • Access checkpoints with Esc+Esc or by typing /rewind
  • Five restore options: code+conversation, conversation only, code only, summarize from here, or cancel
  • Checkpoints only track edits made by Claude's Write/Edit tools — not Bash commands
  • Checkpoints persist across sessions and are cleaned up after 30 days
  • Bash file operations (rm, sed -i, echo > file) are NOT checkpointed
  • Checkpoints are not a replacement for git — they're a session-level safety net
  • To branch off and explore a different path, use --fork-session instead of /rewind

What Checkpoints Track

Definition

A checkpoint is an automatic snapshot created before Claude processes each user message. It captures the state of all files that Claude's file editing tools (Write, Edit, NotebookEdit) have touched in the session, paired with the conversation history up to that point.

Checkpoints are created per prompt, not per file edit. If one user message triggers 12 file edits, those 12 edits are grouped into a single checkpoint. When you rewind to that checkpoint, all 12 edits are undone together — you go back to the state before you sent that message.

Tracked by checkpointsNOT tracked by checkpoints
File edits via the Edit toolFiles modified by Bash commands (sed -i, awk, etc.)
New files created via the Write toolFiles deleted or moved by Bash (rm, mv)
Notebook edits via NotebookEditFiles created by shell scripts Claude ran
Conversation historyManual edits you made outside Claude Code
Edits from concurrent Claude Code sessions
Bash File Changes Are Not Checkpointed

If Claude uses Bash to run `npm run generate:types` which produces files, or `rm old-file.ts`, those filesystem changes are NOT included in the checkpoint. Only changes made by the Write, Edit, and NotebookEdit tools are tracked. This is important for tasks that mix Claude file edits with shell-based file generation.

How to Access Checkpoints

Checkpoints are accessed through the rewind interface. You can open it at any point during or after a session.

1

Open the rewind list

Press Esc twice (Esc+Esc) or type /rewind. A scrollable list appears showing all user prompts from the session, most recent first.

2

Select a checkpoint

Navigate the list to find the message you want to rewind to. Each entry shows your prompt text and a timestamp.

3

Choose a restore option

After selecting a checkpoint, you get five options (see below). Pick the one that matches what you want to undo.

Five options give you precise control over what gets restored

Choosing the Right Restore Option

The five restore options are not all 'undo' — they serve different purposes. Picking the right one depends on what went wrong.

OptionUse it when...
Restore code and conversationClaude went in the wrong direction and you want a clean slate from that point
Restore conversation onlyYou manually fixed the code but want Claude to 'forget' the bad approach in the chat history
Restore code onlyThe code changes were wrong but the conversation context (debugging info, explanations) is useful to keep
Summarize from hereThe conversation is long and you want to free context space without losing file state — a targeted /compact
Never mindYou opened rewind by accident or changed your mind
Summarize From Here Is Underused

The 'Summarize from here' option compresses conversation history from the selected point forward while leaving earlier context and all file changes intact. It's more surgical than /compact, which summarizes everything. Use it to free context space on long sessions without losing the early planning discussion.

Checkpoints and Git: Complementary, Not Competing

Checkpoints and git serve different purposes and operate at different granularities. They are not alternatives — they work together.

CheckpointsGit
GranularityPer user messagePer commit (you decide)
ScopeWithin a sessionPermanent project history
CollaborationLocal onlyShared with team
Duration30 days, then cleaned upPermanent (until explicitly deleted)
Tracks Bash changesNoYes (if staged and committed)
Requires user actionNo (automatic)Yes (git add, git commit)

The recommended workflow: use checkpoints as a session-level safety net while you explore. When you reach a stable state you want to preserve, commit to git. Checkpoints let you experiment freely knowing you can always rewind; git preserves the results of successful experiments for the team.

Commit Early, Checkpoint Always

Before starting a large Claude Code session, make a git commit. This gives you a hard reset point that is not subject to the 30-day checkpoint expiry. Then let checkpoints handle the within-session safety.

Branching Off: When to Fork Instead of Rewind

Sometimes you don't want to throw away the current approach — you want to explore an alternative alongside it. Rewinding discards the current state; forking preserves it.

Use --fork-session to explore an alternative approach without losing the original

Fork is the right choice when you want to try approach A and approach B side by side. Rewind is the right choice when approach A was wrong and you want to start approach B from a clean state.

Best Practices

Best Practices

Do

  • Make a git commit before starting any large Claude Code session — a hard reset point beyond the 30-day checkpoint window
  • Use 'Summarize from here' to free context space on long sessions rather than always using /compact
  • Use Esc+Esc to check checkpoints when something looks wrong — before manually trying to fix it
  • Understand that Bash command side effects are NOT checkpointed — be cautious with shell-based file generation

Don’t

  • Don't rely on checkpoints as your only safety net for important work — commit to git
  • Don't assume all file changes from a session are checkpointed — Bash-produced files are not
  • Don't use /rewind when you actually want to fork — rewinding discards the current state
  • Don't ignore the 30-day expiry — checkpoints for old sessions will be gone

Key Takeaways

  • Checkpoints are per-prompt, automatic, and accessible via Esc+Esc or /rewind
  • Only Write/Edit/NotebookEdit tool changes are tracked — Bash file operations are not
  • Five restore options let you choose what to revert: code, conversation, or both
  • 'Summarize from here' is a surgical alternative to /compact for freeing context space
  • Checkpoints are a session safety net — git is the permanent record

Video on this topic

Claude Code Checkpoints: Undo Any Session State

tiktok