Chapter 8 · Checkpoints

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.

01 · The Problem

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

CheckpointSnapshot of conversation state — messages, files, context
RewindReturn to a previous checkpoint, discarding subsequent changes
Branch pointA checkpoint from which multiple approaches are explored
The mental model: undo for the whole session — not just the file you touched, but the conversation that produced it.
02 · Automatic

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
Because saving is free and automatic, the skill to learn isn't saving — it's knowing when and how to rewind. That's the rest of this chapter.
03 · Access

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.

Make Esc Esc muscle memory — it's the fastest path from "that was a mistake" to "back at the last good state".
04 · The Five Options

The rewind menu asks one question twice: roll back the conversation? roll back the files?

OptionConversationFiles on diskUse when…
1Restore code and conversation rewoundrewound Full reset — the approach was wrong, start the branch over
2Restore conversation rewoundkept The code is fine — re-ask with a cleaner message history
3Restore code keptrewound Keep everything learned in the chat, revert the file changes only
4Summarize from here compresseduntouched Conversation from this point forward becomes an AI summary — frees context
5Never mind keptkept Cancel and return to the current state
Options 1–3 are the grid of two independent switches — conversation and code. Option 4 is the odd one out: it's not an undo at all, it's context management. After restoring the conversation or summarizing, your original prompt is restored into the input field, ready to re-send or edit.
05 · Summarize From Here

"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"
The decision rule: when the window is full but the work is good, summarize; when the work is bad, rewind.
06 · The Gotcha

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 capturedrm, 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
The rule of thumb: anything that touched disk through a shell is outside the snapshot. Rewind reverses Claude's edits; git is the safety net for everything else. Never rely on checkpoints alone for code preservation.
07 · Use Cases

Four workflows, one move: checkpoint, try, rewind, try again

Exploring approachesSave → Try A → Save → Rewind → Try B → Compare
Safe refactoringSave → Refactor → Test → If fail: Rewind
A/B testingSave → Design A → Save → Rewind → Design B → Compare
Mistake recoveryNotice 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.

All four are the same primitive wearing different hats: a known-good state you can always return to makes trying things cheap.
08 · Branching

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):

Baseline
"Optimize the API response time"
checkpoint created automatically
450 ms
try · rewind
· try again
Branch 1Redis caching
280 ms  ·  −38%
Branch 2 · winnerQuery optimization
180 ms  ·  −60%
Branch 3Compression + CDN
320 ms  ·  −29%
Combine
rewind to the winner's checkpoint,
add caching on top
95 ms · −79%
commit
FinalOptimized queries + Redis
95 ms
Each branch rewinds to the identical baseline with "Restore code and conversation" — so the numbers are honest. And rewind targets aren't only the start: rewind to any mid-session checkpoint to stack a second win on the first.
09 · The Example Shelf

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.

Notice what the debugging example proves: rewinding between hypotheses keeps each test uncontaminated by the failed fixes before it.
10 · Git Integration

Checkpoints are for minutes, git is for forever — they complement, never replace

ScopeGit: file system · Checkpoints: conversation + files
PersistenceGit: permanent · Checkpoints: session-based
GranularityGit: commits · Checkpoints: any point
SpeedGit: slower · Checkpoints: instant
SharingGit: 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
The division of labor: checkpoints answer "which approach?" — fast, local, disposable. Git answers "what shipped?" — permanent, auditable, shareable.
11 · Configuration

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 checkpointsThe rewind history itself
~/.claude/tasks/Persistent task lists
~/.claude/shell-snapshots/Captured shell-environment snapshots
~/.claude/backups/Rolling setting / CLAUDE.md backups
One number, four caches, pruned uniformly after the same period — raise it to keep rewind history longer, at the cost of disk.
12 · Practice

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
All three don'ts are the same lesson from section 06 wearing different clothes: the snapshot has edges — git covers what's beyond them.
13 · When to Rewind

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
Two rewind triggers, two cures: bad direction → restore; good direction, bloated window → summarize.
14 · Recap

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.

Try it now: make any change, press Esc Esc, and read your own checkpoint list. Chapter 9: advanced features — permission modes, planning mode, background tasks, and headless operation.
Sid Dani · June 2026