Claude Code checkpoints and rewind: what you can and can't undo

Claude Code checkpoints let you undo the file edits Claude makes during a session. Every prompt you send that starts a turn creates a restore point, and you can roll your files, the conversation or both back to it by pressing Esc twice or running /rewind. For a session that goes wrong on a website template or a batch of pages, that is the fastest way back to where you were.

Checkpoints have hard limits, though. They don't track changes made by shell commands, they usually don't cover edits made by subagents, and they can't undo anything that left your machine, such as a deploy, a database change or a call to your CMS. Anthropic's own docs say checkpoints are for "quick, session-level recovery" and that you should keep using git for real version history. This guide explains exactly what a rewind restores as of October 2026, what it misses, and how to combine it with git so nothing on your site depends on luck.

What a checkpoint is

A checkpoint is a restore point Claude Code saves automatically. In the words of Anthropic's checkpointing docs, it "captures the state of your code before each prompt you send that starts a turn." Before Claude edits a file with its own editing tools, it snapshots the file's current contents, so a later rewind can put those contents back.

A few details matter in practice:

• No setup. Checkpointing is on as soon as you start a session. You don't name or save checkpoints yourself.
• Per prompt, not per edit. If one prompt leads Claude to change twelve files, rewinding to before that prompt restores all twelve together.
• Saved with the conversation. Close the terminal, resume the session tomorrow with claude --continue, and you can still rewind.
• A rolling window. File snapshots are kept for the 100 most recent checkpoints in a session.
• An expiry date. Snapshots are deleted in Claude Code's retention sweep, by default about 30 days after the session last saved one. Rewinding to a checkpoint whose snapshots are gone can fail with a "No files were restored" message. The cleanupPeriodDays setting changes the retention period.

How to rewind, step by step

In the terminal, the rewind menu works like this:

1. Press Esc to stop Claude if it is still working.
2. Make sure the prompt input is empty. If it has text in it, a double Esc clears the text instead (it is saved to your input history, so the Up arrow brings it back later).
3. Press Esc twice, or type /rewind. The menu lists the prompts you sent during the session.
4. Pick the prompt you want to go back to, then choose an action from the list below.
5. Check the result. Run /diff or git status and open the page in your browser to confirm the files are what you expect.

The actions, as listed in Anthropic's docs:

The two code-restore options only appear when the checkpoint has tracked file changes to revert. After you restore the conversation, your original prompt is put back in the input box so you can edit and resend it. That helps when the first prompt was too vague.

The summarize options don't touch files. They free up context, which our guide to context, compaction and memory covers in depth.

In VS Code

The VS Code extension supports checkpoints too. Hover over a message to reveal the rewind button, which offers three choices: "Fork conversation from here", "Rewind code to here", and "Fork conversation and rewind code." The same limits apply. Other surfaces change often, so check the current docs for the one you use.

What checkpoints don't track

This is the part that catches people. A rewind looks like a full undo, but it only covers one kind of change. Anthropic's docs list these limits:

• Bash commands. "Checkpointing does not track files modified by Bash commands." If Claude runs a script that rewrites 300 HTML files, or deletes and moves files with rm and mv, rewind can't bring them back. On website projects, bulk edits often run as scripts, so this is the most common gap.
• Remote systems. "Actions that affect remote systems (databases, APIs, deployments) can't be checkpointed." A deploy, a push to GitHub, a WordPress database update or a change made through a CMS connection stays done after a rewind.
• Subagent edits. Claude Code "usually doesn't capture those edits in your session's checkpoints." The docs' advice for those is plain: "Use git to revert them." The exception is a skill set to run as a forked subagent in the foreground. See subagents explained for how subagents work.
• Changes made outside the session. Edits you make by hand in your editor, and edits from other Claude Code sessions running at the same time, are "normally not captured, unless they happen to modify the same files as the current session."
• Symlinked and hard-linked files. A restore skips them and warns you that it skipped some files.
• Messages typed while Claude was working. These get no checkpoint of their own and are marked "No code restore" in the menu. To undo that part of the work, rewind to the prompt that started the turn.

The practical rule: a rewind undoes what Claude typed into files with its editor, during this session. Everything else needs git or a backup.

Checkpoints vs git

Git is version control: a permanent history of committed changes that you can share, review, branch and roll back. Checkpoints are a private, short-lived undo stack for one session. They complement each other, and you need both.

If git is new to you, start with git basics for Claude Code. You only need a handful of commands: check status, commit, create a branch, and discard changes.

A working routine that uses both

On a website project, this routine keeps every change recoverable:

1. Start from a clean, committed state on a branch. Run git status before the session. If it shows uncommitted changes, commit or stash them first, so you can always get back to a known good copy.
2. Work on a copy of the site, not the live server. Our guide to setting up a staging site explains how.
3. Let checkpoints cover experiments. Try a new header layout, look at it in the browser, and rewind with Restore code if you don't like it.
4. Commit when something works. Ask Claude to commit with a clear message, or do it yourself. A commit is the point you can return to next week.
5. Before any script that edits many files, commit first. Because rewind can't undo a script's changes, the commit is your undo. A prompt such as Before running the rewrite script, commit the current state with the message "before meta rewrite", then run it on three pages only and show me the diff builds that habit in.
6. Review the diff before anything leaves your machine. Pushes and deploys can't be rewound, so a person reads the change first.

The check that proves the routine works: at any moment, git log should show a recent commit you could go back to, and git status should show only the changes from the current task.

What we learned running eseospace.com

Two lessons from our own 2,200-page site, both described in our eseospace.com rebuild case study, show why checkpoints alone aren't enough. Our September 2026 accuracy audit applied more than 4,400 corrections across about 750 pages as scripted edits, each tested on a copy first. Changes made by scripts are exactly the kind a checkpoint doesn't track.

We also had two sessions working on the same site, and one regenerated pages the other had just edited, so those edits disappeared. A checkpoint in the first session could not have helped, because the overwrite came from a different session. What catches that is a habit: check git history for changes you didn't make before any deploy. More of these cases are in common Claude Code mistakes on websites.

When rewind is the right tool, and when it isn't

Because remote actions can't be undone this way, the permission settings that stop Claude from pushing or deploying on its own matter more than any undo button. Our article on whether Claude Code is safe for a live website covers those settings.

Conclusion

Checkpoints make Claude Code safer to experiment with: you can try a change, look at it and back out in seconds with Esc twice or /rewind. They are not a backup. They miss script and shell changes, most subagent edits, other sessions, your own manual edits and everything that reaches a server. Treat them as a short-term undo, and keep git commits, a staging copy and a person approving deploys as the real safety net. If you want a team setup with branches, permission rules and a review process built in, our Claude Code consulting covers it. More guides are in our Claude Code Guide.

Frequently asked questions