How to roll back a bad change (checkpoints are not git)

Claude Code automatically snapshots your code state before every prompt you send (a checkpoint), and you can /rewind back to one at any time. But it only tracks changes Claude made with its file-editing tools — bash commands, subagents, and your own edits in the editor are all outside its protection. Treat it like git and it will bite you eventually.

One-line answer

Answer When things break, first /rewind (or press Esc twice) back to the checkpoint before the damage; but a checkpoint is only “session-level undo” — bash changes, subagent edits, and external modifications are beyond its reach, and those take git. OfficialThe official positioning, in spirit: a checkpoint is local undo, git is permanent history; the former complements the latter, never replaces it.

Steps

Open the rewind menu. Run /rewind, or press Esc twice while the input box is empty. OfficialThe menu lists every prompt you sent this session — each prompt automatically created a checkpoint. The session keeps file snapshots for the most recent 100 checkpoints, and checkpoints persist with the session, so you can still rewind after resuming it (sessions are cleaned up after 30 days by default, adjustable via cleanupPeriodDays).
Choose the restore point and what to restore. OfficialAfter selecting a prompt there are three kinds of restore: code + conversation, conversation only (code stays as it is), and code only (conversation kept — for “right idea, wrong edits”). Two further Summarize options compress context and never touch files on disk. Expected: after restoring code, files Claude edited return to their content at that checkpoint.

Check which changes were NOT rolled back. This is the crux of this tip — Officialcheckpoints explicitly do not track:

Source of change	Can /rewind restore it?	What to do
Claude’s file-editing tools (Edit/Write)	Yes	Rewind freely
Bash commands (`rm`/`mv`/`cp`, scripts, code generators)	No	git or manual recovery
Subagent edits (incl. background `/code-review --fix`)	No (foreground forks are the exception)	Roll back with git
Your own editor changes, other concurrent sessions	Not tracked	Use git
Files behind symlinks/hardlinks	Skipped, with a warning	Manual, or have Claude edit them back

If restoring code shows a “Restored the code, but skipped N files” warning, link-type paths were skipped; run /debug to enable logging first, then rewind — the log names every skipped path. Official

Build the division-of-labor habit. Our takeThe working rule: start with a clean working tree (git as the safety floor), let Claude charge at big experimental changes — if it fails, rewind and try another angle; commit milestones promptly. That way rewind covers “minute-scale trial and error” and git covers “hour-scale milestones,” two layers of insurance that stay out of each other’s way. For the full checkpoint mechanism, see D6 · the checkpoints & session management lesson; to break less in the first place, pair this with give it checks it can run itself.

Copy-paste prompt

Your last changes broke the project. Stop — do not make any more edits. Help me evaluate rollback options:
1. List every file you changed with the file-editing tools in this session (these I can restore with /rewind).
2. List the file changes you made through bash commands (created/deleted/moved/rewritten by scripts — /rewind
   cannot restore these), and give the exact git commands to recover them (git status / git checkout / git clean).
3. Tell me the recommended recovery order, and how to verify the project is back in a working state afterwards.
Analysis only — do not run any recovery commands yet.

Sources & last verified

OfficialCheckpointing — automatic snapshots, 100 checkpoints, the five rewind-menu options, the four kinds of untracked changes, local undo vs permanent history; fetched 2026-08-05.
Last verified: 2026-08-05 · volatility: high (tied to checkpoint behavior details and versions; re-checked periodically).