Claude Code Checkpoints and /rewind: Undo Changes Safely

Most people use Claude Code too carefully. They approve every small step, avoid big refactors and never ask for the bold version, because undoing a mess feels expensive. Claude Code already has a fast undo built in. Once you understand what it covers and what it does not, you can let Claude try things you would never risk by hand.

This guide covers how checkpoints work, how to rewind, and the habits that make experimenting safe.

What a checkpoint is

Every prompt you send that starts a turn creates a checkpoint. Before Claude edits anything in that turn, Claude Code records the state of the files its editing tools touch. You do not turn this on. It is always there.

A few details worth knowing:

• Claude Code keeps file snapshots for the 100 most recent checkpoints in a session.
• Checkpoints are saved with the conversation, so you can still rewind after you close the terminal and resume the session later.
• Snapshots are cleaned up with old sessions, by default about 30 days after the session last saved one. The cleanupPeriodDays setting changes that.

How to rewind

Press Esc twice with an empty prompt, or type:

/rewind

/checkpoint and /undo open the same menu. If there is text in your prompt, the first double Esc clears it instead. The cleared text goes to your input history, so press the up arrow to get it back later.

The menu lists the prompts you sent in this session. Pick the point you want, then choose what to do:

• Restore code and conversation: go back completely, as if the later turns never happened.
• Restore conversation: rewind the chat but keep the files as they are now.
• Restore code: revert the files but keep the conversation, so Claude remembers what it tried.
• Summarize from here: compress everything after that point into a summary to free up context.
• Summarize up to here: compress everything before that point and keep the recent messages intact.

Restore code is the one I use most. The attempt failed, but the conversation about why it failed is useful. Claude keeps that knowledge and the files go back to clean.

Rewind past a /clear

If you ran /clear earlier in the same Claude Code process, the rewind menu shows an extra entry at the top labeled with the previous session. Select it to go back to the conversation you cleared. This needs Claude Code v2.1.191 or later. On older versions, run /resume and pick the previous session instead.

What checkpoints do not cover

This is the part people skip, and it is the part that matters. Checkpoints track edits made by Claude's file editing tools in the current session. They do not track:

• Shell commands. If Claude runs rm, mv, cp, a formatter, a code generator or a database migration, rewind will not undo it.
• Most subagent edits. Changes made by subagents usually are not captured in your session's checkpoints. Use Git to revert those.
• Your own edits in your editor, or edits from another Claude Code session running at the same time.
• Symlinked and hard linked files. A restore skips them and tells you how many it skipped.
• Anything outside your machine. A pushed commit, a deployed build, a sent email or a changed database record is not coming back with a rewind.

So think of checkpoints as a fast local undo for file edits. They are not a backup, and they are not version control.

The safe way to be bold

Here is the routine I use when I want Claude to try something ambitious, like a large refactor or a new layout approach.

First, commit. This is your real safety net, and it covers everything checkpoints miss.

git add -A
git commit -m "Before layout experiment"

Then ask for the bold version, and be explicit about the limits:

Try the aggressive version of this: rebuild the settings screen
as a single scrolling page instead of tabs. Don't ask me to
confirm each step. Only change files with your edit tools.
Do not run migrations, delete files from the shell, install
packages or push anything. When you're done, list every
file you changed and what you'd do differently.

Keeping Claude to its edit tools is what makes the undo reliable. Anything it does through the shell sits outside the checkpoint, and the commit above is what covers it.

Then look at the result. If it works, commit it. If it does not, press Esc twice, pick the prompt where you asked for the experiment, and choose Restore code. Then tell Claude what you learned and try the next idea.

Compare two approaches

Sometimes you want to keep both versions instead of throwing one away. Two tools help here.

/branch creates a branch of the current conversation at this point, so you can try a different direction without losing the conversation as it stands. You return to the original with /resume. It copies the conversation, not your files, so commit or stash before you switch approaches.

For real parallel work, start a separate session in its own Git worktree:

claude --worktree layout-b

That gives the second attempt its own copy of the files, so the two approaches never overwrite each other. When you have picked a winner, merge it like any other branch.

Where rewind fits

I think of three layers. Rewind is for the next few minutes: a turn that went wrong, a suggestion I did not like. Git commits are for the day: every state I might want to return to. Worktrees are for real alternatives I want to compare side by side. Using the right layer for the job is what lets you move fast without being careless.

Try it on your next task. Commit, ask Claude for the version you would normally hold back on, and practice one rewind with Restore code. Once you have undone something in two keystrokes, you will stop protecting Claude from its own ideas.