Claude Code Checkpoints: How /rewind Works and What It Can't Undo

Claude Code keeps an undo history. Before each prompt you send, it snapshots the files it's about to work on, and you can rewind to any of those points. It's one of the most reassuring features in the tool — and one of the most misunderstood, because it undoes less than people assume.

This guide covers how to use it, and draws a precise line around what it can and can't bring back.

Details reflect Claude Code as of September 2026. See the checkpointing documentation.

How to rewind

Press Esc twice with an empty prompt, or run /rewind. You get a list of the prompts you've sent this session. Pick one, then choose:

Option	What it does
Restore code and conversation	Both go back to that point
Restore conversation	Rewind the chat, keep the current files
Restore code	Revert the files, keep the chat
Summarize from here	Compress everything after this point to free up context
Summarize up to here	Compress everything before it

Restore code is the one to reach for when Claude went down a bad path but the conversation taught it something: the files go back, but Claude remembers why the attempt failed and won't repeat it.

Restore conversation is useful the other way round: the code is fine, but the conversation took a detour you'd like to erase from its context.

The summarize options aren't undo at all — they're a targeted way to shrink a long session without losing your original instructions.

Checkpoints are saved with the conversation, so rewinding still works after you resume a session. By default they're kept for about 30 days, and each session keeps snapshots for its 100 most recent checkpoints.

What checkpoints cover

Only one thing: changes made through Claude's own file-editing tools, in your session. When Claude uses its Edit or Write tool on a file, the previous version is captured.

That's most code changes, which is why rewind feels so effective in normal use.

What checkpoints don't cover

Here's the list that matters. Anthropic's docs are explicit about each one.

1. Anything done with a shell command. If Claude runs rm file.txt, mv old.txt new.txt, sed -i, a code generator, or a formatter from the command line, those changes are not tracked. Rewinding won't restore a file a shell command deleted.

2. Most subagent edits. Edits made by subagents usually aren't captured in your session's checkpoints. Rewinding won't undo them; git will.

3. Changes outside the session. Edits you make by hand in your editor, or from another Claude session running at the same time, aren't tracked.

4. Symlinked and hard-linked files. Rewind skips them, and warns you when it does.

And then there's the category the docs don't need to mention, because it's obviously outside any file snapshot:

5. Everything that isn't a file in your project.

Database changes. A migration that dropped a column, a script that deleted test users, an UPDATE without a WHERE. None of it is in a checkpoint.
Installed packages and system state. npm install of the wrong version, a global tool, a changed config in your home directory.
Anything pushed. A git push, a force-push, a deployed release.
Anything sent. An API call that charged a card, sent an email, posted a message, created a ticket, or changed a setting on a third-party service.

Notice the shape of that list. The things checkpoints protect are the things that are easy to fix anyway — a bad edit to a source file. The things they can't protect are the ones that hurt: lost data and actions in the outside world.

Filling the gaps

Checkpoints are one layer. Here's what covers the rest.

Git, for everything in the repository. Commit before any risky step and at every point you'd like to return to. git status and git diff show exactly what changed, whatever changed it — edit tool, shell command, or subagent. Git sees everything in the working tree; checkpoints see only one kind of change. And if things go truly wrong, git's reflog can recover commits you thought were gone — see How to Undo Almost Anything in Git.

Backups, for the database. Development databases deserve backups too if they hold data that took effort to create. Production databases need backups you've actually restored from. And the best protection is structural: the agent shouldn't have production credentials at all. How to Back Up a Postgres Database and How to Stop an AI Agent From Deleting Your Production Database cover both.

Permissions and hooks, for irreversible actions. Pushes, deploys, deletions, and anything that sends something to the outside world should require approval, or be blocked by a hook. Undo is the wrong tool for actions that can't be undone. See Claude Code Hooks.

An environment that limits the blast radius. If the agent can only reach this project's files and this project's development database, the worst case of any mistake is bounded — no matter which layer it slips through.

A workflow that uses all of it

Commit before starting a task.
Use plan mode for anything substantial, so the direction is agreed before edits begin. (Here's how.)
Let Claude work. Use /rewind → Restore code freely for bad edits — it's instant and keeps the lesson in the conversation.
Before anything touching the database or the outside world, pause and check: is there a backup, is this the right environment, is this reversible?
Commit at each working state. Push when you're happy.

The one-line version

/rewind undoes Claude's file edits. Git undoes changes to your repository. Backups undo changes to your data. Nothing undoes a message that's already been sent — so make those ask first.

EasySpawn gives every workspace a managed database with daily backups, keeps GitHub as the canonical source of your code, and runs the agent in an isolated container — so the mistakes checkpoints can't undo have somewhere else to be undone. See how it works or join the waitlist.