Checkpointing and Rewind in Claude Code — Undo Anything, Fearlessly

When an AI coding assistant makes a wrong turn — breaks your layout, adds an unwanted feature, or rewrites a file in a direction you never asked for — what do you do? You could manually undo each change, ask the AI to reverse its work, or dig through your Git history. None of these options are quick or reliable.

Checkpointing in Claude Code solves this problem. It automatically captures the state of your code before every edit, so you can rewind to any previous point in your session — restoring your files, your conversation, or both — with a single command. Think of it as an undo stack built directly into your AI coding workflow.

This feature is one of the reasons Claude Code encourages bold, ambitious edits. When you know you can always go back, you explore more confidently.

What You Will Learn

1. What checkpointing is and why it matters for agentic coding.
2. How checkpoints are created and stored automatically.
3. How to trigger the rewind menu (Esc + Esc or /rewind).
4. The five actions available in the rewind menu.
5. The difference between restoring and summarizing.
6. How checkpointing connects to the CAIR (Confidence in AI Results) framework.
7. Common use cases and practical workflows.
8. Limitations you need to be aware of.

What Is Checkpointing?

Definition

Checkpointing is a built-in mechanism that automatically tracks every file change Claude Code makes during a session. Each time you send a prompt and Claude edits your code, a new checkpoint is created — a snapshot of your files at that moment. You can then rewind to any of those snapshots whenever you need to.

The Analogy

Imagine you are writing a long essay in a word processor that auto-saves after every paragraph. At any point, you can open a version history and jump back to the state after paragraph 3, paragraph 7, or any other point. Checkpointing does the same thing for your coding session: every prompt you send is like a paragraph boundary, and Claude Code saves a snapshot at each one.

Why It Matters

In agentic coding, the AI assistant often modifies multiple files in a single turn. One wrong instruction can cascade across your codebase. Without a safety net, you would have to manually identify and revert each change — a tedious and error-prone process. Checkpointing removes that fear entirely:

1. Explore freely: Try experimental approaches knowing you can revert in seconds.
2. Iterate faster: Undo a wrong turn and re-prompt with better instructions instead of layering fixes on top of mistakes.
3. Maintain confidence: The ability to undo reduces the risk of delegating large-scale edits to the AI.

How Checkpoints Work

Automatic Tracking

You do not need to configure anything. Claude Code tracks all changes made by its file editing tools automatically:

1. Every user prompt creates a new checkpoint.
2. Checkpoints persist across sessions — you can access them in resumed conversations.
3. Checkpoints are automatically cleaned up along with sessions after 30 days (configurable).

Only changes made through Claude Code's file editing tools are tracked. This is an important distinction that we will revisit in the Limitations section.

What Is Captured

Each checkpoint records:

1. The state of every file that Claude Code edited at that point in the session.
2. The conversation history up to that prompt.

This dual tracking — code and conversation — is what makes the rewind feature so powerful. You can restore one, the other, or both.

The Rewind Menu

How to Open It

There are two ways to open the rewind menu:

1. Press Esc twice (Esc + Esc) — the quickest way to reach the menu.
2. Type the slash command /rewind — use this if you prefer explicit commands.

Both methods open a scrollable list of your prompts from the current session. Each entry represents a checkpoint — a point in time you can jump back to.

The Five Actions

After selecting a checkpoint from the list, you are presented with five actions:

After choosing any of the three restore actions, the original prompt from the selected message is automatically restored into your input field. This lets you re-send it as-is or edit it with refined instructions before sending.

Example Walkthrough

Imagine you are building a landing page and have sent the following prompts:

1. Prompt 1: "Create a responsive hero section with a call-to-action button."
2. Prompt 2: "Add a three-column features section below the hero."
3. Prompt 3: "Add a testimonials carousel at the bottom."
4. Prompt 4: "Add a dark footer with social links and a newsletter form."

After prompt 4, you realise the footer doesn't match your design. You press Esc + Esc, scroll down to Prompt 3 (after the testimonials), and choose "Restore code and conversation". Your files and conversation revert to the state right after the testimonials were added. The footer is gone, and your input field now contains your original prompt 4 text. You edit it:

Claude Code creates a different footer — one that matches your vision.

Restore vs. Summarize

How Restore Works

The three restore options revert state. They undo code changes, conversation history, or both, effectively rolling back to the selected checkpoint. Everything after that point is discarded from the active session.

How Summarize Works

"Summarize from here" works differently from the restore actions:

1. Messages before the selected message stay intact — untouched.
2. The selected message and all subsequent messages get replaced with a compact, AI-generated summary.
3. No files on disk are changed.
4. The original messages are preserved in the session transcript, so Claude can reference the details if needed.

This is similar to the /compact command, but targeted: instead of summarising the entire conversation, you keep early context in full detail and only compress the parts that are using up space. You can also type optional instructions to guide what the summary focuses on.

When to Use Each

Key distinction: Summarize keeps you in the same session and compresses context. If you want to branch off and try a different approach while preserving the original session completely intact, use --fork-session instead.

Connection to CAIR — Confidence in AI Results

What Is CAIR?

CAIR (Confidence in AI Results) is a framework introduced by Assaf Elovic and Harrison Chase of LangChain for measuring and building user trust in AI systems. It is defined by a simple formula:

1. Value: The benefit the AI delivers (time saved, code produced, bugs fixed).
2. Risk: The potential damage from incorrect output (data loss, security holes, broken builds).
3. Correction: The effort required to fix mistakes (manual undo, Git archaeology, rewriting from scratch).

To maximise confidence (CAIR), you want high Value and low Risk × Correction.

How Checkpointing Improves CAIR

Checkpointing directly targets the Correction factor. Without it, correcting a multi-file mistake could take minutes of manual reverting. With checkpointing, correction drops to a single rewind action — a few seconds at most.

The CAIR paper outlines five principles for building human-AI trust. Checkpointing maps to two of them:

1. Reversibility: "Every action should be easily reversible." Checkpointing is the literal implementation of this principle — every edit Claude makes can be reversed instantly.
2. Consequence Isolation: "Limit the blast radius of any single action." Because checkpoints are scoped to the session and individual prompts, the blast radius of any mistake is contained to the changes since the last checkpoint.

The practical result: when correction is near-zero, you feel comfortable asking Claude Code to make bigger, more ambitious changes. You delegate more, and the total Value delivered by the AI increases.

Common Use Cases

Exploring Alternative Implementations

You ask Claude Code to implement a feature one way, review the result, rewind, and try a completely different approach — without losing your starting point.

Recovering from Mistakes

Claude introduces a bug or misunderstands your request. Instead of debugging the mistake on top of broken code, rewind to the last known good state and re-prompt with clearer instructions.

Iterating on Design

You are styling a component and want to try three different visual approaches. After each attempt, rewind to the base version and try the next one.

Freeing Context Window Space

You have been debugging for 20 prompts and the conversation is long. The early context (your initial architecture decisions) is more important than the verbose debugging exchanges in the middle. Use "Summarize from here" on the debugging section to compress it, keeping your architecture context intact.

Practical Workflow: Building and Refining a Component

Let's walk through a realistic scenario step by step.

Step 1 — Bootstrap the Project

Claude Code scaffolds the project. A checkpoint is automatically created.

Step 2 — Add a Feature

Claude adds the endpoint. Another checkpoint is created.

Step 3 — Add Another Feature

Claude configures Swagger and adds XML comments. Another checkpoint.

Step 4 — Something Goes Wrong

Claude restructures the entire project, but the result is over-engineered for your needs. You had a simpler architecture in mind.

Step 5 — Rewind

Your code and conversation revert to the state after Step 3. The REPR refactoring is gone. Your original prompt from Step 4 appears in the input field.

Step 6 — Re-prompt with Better Instructions

This time, Claude follows a simpler path because your instructions are clearer and more constrained.

Limitations

Bash Command Changes Are Not Tracked

Checkpointing only tracks files modified through Claude Code's file editing tools. If Claude runs a bash command that modifies files, those changes are not captured and cannot be undone through rewind:

External Changes Are Not Tracked

If you manually edit a file in another editor while Claude Code is running, those changes are normally not captured by the checkpoint system — unless they happen to modify the same files that Claude edited in the current session.

Not a Replacement for Version Control

Checkpoints are designed for quick, session-level recovery. They are not a substitute for Git:

1. Continue using Git for commits, branches, and long-term history.
2. Checkpoints complement but do not replace proper version control.
3. Think of checkpoints as "local undo" and Git as "permanent history".

A good practice is to commit your work at stable points before asking Claude Code to make large-scale changes. That way, you have both the checkpoint safety net and a Git commit to fall back on.

Best Practices

1. Commit before big changes. Run git commit before asking Claude Code to refactor, restructure, or add a major feature. This gives you both a checkpoint and a Git safety net.
2. Write clear, scoped prompts. Each prompt creates one checkpoint. If you bundle too many instructions into a single prompt, you lose granularity — you can only rewind to the start of that prompt, not to an intermediate point within it.
3. Use "Summarize from here" in long sessions. Long debugging exchanges eat up context window space. Summarize the verbose middle section to free space while keeping your initial instructions and architecture decisions intact.
4. Use restore options strategically. "Restore code" is useful when Claude broke your files but the conversation context is still valuable. "Restore conversation" is useful when the code is fine but the conversation drifted.
5. Distinguish checkpoints from forks. Rewind replaces the current session state. If you want to branch off and explore while keeping the original session intact, use claude --continue --fork-session instead.

Summary

Checkpointing is one of Claude Code's most important safety features. It automatically snapshots your code at every prompt, lets you rewind to any previous state (code, conversation, or both), and lets you compress verbose sections via targeted summaries. Combined with Git, it creates a two-layer safety net: checkpoints handle short-term, session-level recovery, while Git handles long-term, persistent history.

The result is a dramatic reduction in the Correction factor of the CAIR equation. When correction is cheap, you trust the AI more, delegate more, and get more value from your agentic coding workflow.