Checkpoints — Undo for the Whole Session
Every prompt you send drops an automatic save point. Rewind with Esc Esc or /rewind, choose from five restore options, branch between competing approaches — and learn the one thing checkpoints can never see: what your bash commands did to disk.
Risky changes stop being risky when every conversation state is a save point
Big refactors, speculative rewrites, "let's just try it" — the real cost is losing a working state you can't get back to. Checkpoints are snapshots of your conversation state that let you rewind to previous points in a session — for exploring different approaches, recovering from mistakes, or comparing alternative solutions.
What a checkpoint captures
- All messages exchanged
- File modifications made
- Tool usage history
- Session context
Three words to know
| Checkpoint | Snapshot of conversation state — messages, files, context |
| Rewind | Return to a previous checkpoint, discarding subsequent changes |
| Branch point | A checkpoint from which multiple approaches are explored |
You never save manually — every user prompt creates a checkpoint on its own
Checkpoints are a built-in default behavior: no configuration to enable, no save command to remember. Claude Code manages the whole lifecycle for you.
- Every user prompt — a new checkpoint is created with each input you send
- Persistent across sessions — rewind to a point from a few minutes ago or from days before
- Auto-cleaned after 30 days — old checkpoints are pruned automatically so storage never grows without bound
Two doors into the checkpoint browser: press Esc twice, or type /rewind
# keyboard shortcut Esc + Esc # slash command /rewind # alias — same interface /checkpoint
Both open the same browser: a list of all available checkpoints with timestamps. Select any one to rewind to that state.
Each checkpoint shows
- Timestamp of when it was created
- Files that were modified
- Number of messages in the conversation
- Tools that were used
The basic workflow
Work normally → want to go back? Esc Esc → choose a checkpoint → select what to restore → continue from there.
The rewind menu asks one question twice: roll back the conversation? roll back the files?
"Summarize from here" trades message detail for context headroom — nothing on disk moves
Pick a checkpoint and Claude compresses everything from that point forward into an AI-generated summary, freeing context window space. It's the option you reach for after a long debugging session — 20+ messages of exploration that you want condensed, not erased.
- Messages before the selected point stay fully intact
- No files on disk are changed — this is purely about the conversation
- The original messages are preserved in the session transcript — the summary replaces only what's visible
- You can optionally provide instructions to focus the summary — e.g. "Focus on what we tried and what worked"
Checkpoints never see what bash did — rm, mv, and cp are invisible to rewind
This is the limitation that bites people. Checkpoints track the files Claude itself modifies — but bash command changes are NOT tracked. If a shell command deleted, moved, or copied files, "Restore code" will not bring them back.
- Bash operations aren't captured — rm, mv, cp on the filesystem happen outside the snapshot
- External changes aren't captured — edits made in your editor or another terminal, outside Claude Code, are equally invisible
- Not a replacement for version control — use git for permanent, auditable changes to your codebase
Four workflows, one move: checkpoint, try, rewind, try again
| Exploring approaches | Save → Try A → Save → Rewind → Try B → Compare |
| Safe refactoring | Save → Refactor → Test → If fail: Rewind |
| A/B testing | Save → Design A → Save → Rewind → Design B → Compare |
| Mistake recovery | Notice issue → Rewind to last good state |
The safe-refactoring pattern in full: current state is checkpointed automatically → start refactoring → run tests → tests pass: keep working · tests fail: rewind and try a different approach. The checkpoint costs nothing; the failed experiment costs nothing either.
Branch from one baseline, measure each path, then rewind to the winner and stack
From the chapter's performance-optimization session — bar length = response time (shorter is better):
checkpoint created automatically
· try again
add caching on top
The chapter ships eight replayable sessions — nearly every one pivots on Esc Esc
1Architecture bets
Database migration (direct cutover vs dual-write — 15 failing tests trigger the rewind) · API design (REST → GraphQL → back to the REST checkpoint) · configuration management (env vars vs validated YAML).
2Iteration loops
Performance optimization (the three-branch session from the last section) · UI/UX layouts (sidebar → top-nav → card grid → combine) · test strategy (unit → integration → optimize speed → E2E).
3Recovery & housekeeping
Debugging hypotheses (event listeners? connections? — rewind between each until circular references confess) · summarize-from-here after a 20+ message debugging session.
The shared shape of the rewind examples: name a starting checkpoint, try a hypothesis, "Restore code and conversation" back to it, try the next — and only the winner gets committed.
Checkpoints are for minutes, git is for forever — they complement, never replace
| Scope | Git: file system · Checkpoints: conversation + files |
| Persistence | Git: permanent · Checkpoints: session-based |
| Granularity | Git: commits · Checkpoints: any point |
| Speed | Git: slower · Checkpoints: instant |
| Sharing | Git: yes · Checkpoints: limited |
Use both together
- Checkpoints for rapid experimentation
- Git commits for finalized changes
- Create a checkpoint before git operations
- Commit successful checkpoint states to git
One setting governs it all — cleanupPeriodDays now prunes four caches at once
{
"cleanupPeriodDays": 30
}
The only checkpoint-related setting: how many days session history and checkpoints are retained (default 30). Checkpointing itself needs no configuration — it's on by default.
Since v2.1.117, it governs four directories
| Session checkpoints | The rewind history itself |
| ~/.claude/tasks/ | Persistent task lists |
| ~/.claude/shell-snapshots/ | Captured shell-environment snapshots |
| ~/.claude/backups/ | Rolling setting / CLAUDE.md backups |
Review before you rewind — and know the two failures you might meet
✅ Do
- Review available checkpoints before rewinding
- Use rewind to explore different directions
- Keep checkpoints to compare approaches
- Understand each restore option before choosing
❌ Don't
- Rely on checkpoints alone for code preservation
- Expect them to track external file system changes
- Use them as a substitute for git commits
| Missing checkpoints? | Check if checkpoints were cleared · check disk space · ensure cleanupPeriodDays is set high enough (default 30) |
| Rewind failed? | Ensure no uncommitted changes conflict · the checkpoint may be corrupted · try rewinding to a different checkpoint |
The trigger isn't always bad code — sometimes it's a full context window
Checkpoints let you go back, but how do you know when? As the conversation grows, Claude's context window fills and model quality silently degrades — you might be shipping code from a half-blind model without realizing it.
- The chapter points to cc-context-stats, a community status-bar tool that shows real-time context zones
- Plan (green) — safe to plan and code · Code (yellow) — avoid starting new plans · Dump (orange) — finish up and rewind
- When the zone shifts, it's time to checkpoint and start fresh — or "Summarize from here" — instead of pushing through with degraded output
Experiment fearlessly — every prompt is a save point, and git catches what rewind can't
Every user prompt automatically creates a checkpoint — messages, file modifications, tool history, context — persistent across sessions and pruned after cleanupPeriodDays (default 30). Open the browser with Esc Esc or /rewind, then choose: restore code and conversation, conversation only, code only, summarize from here, or never mind. Branch from one baseline to compare approaches, rewind between debugging hypotheses, summarize long sessions to reclaim context. And remember the edges: bash operations, external edits, and anything permanent belong to git — checkpoints are for rapid experimentation, commits are for finalized work.