Claude Code Rewind and Plan Mode: Undo Risky Changes
How to undo Claude Code changes: what /rewind restores and what it cannot, how plan mode holds edits for review, and why git stays your real safety net.
By Matthews WongReviewed on Checked against Claude Code v2.1.301
Key takeaway
Claude Code takes a checkpoint of your files before each prompt that starts a turn, and /rewind can restore code, conversation, or both. It only tracks edits made through Claude's file-editing tools. Plan mode holds edits back until you approve a plan. Neither replaces git: commit before a risky change.
You will be able to
- Use /rewind to restore code, conversation or both, and know which edits it cannot see.
- Use plan mode to review a change before any source file is touched.
- Order a risky change so that git, not hope, is the final undo.
Step through the diagram
Press Play, or step with the arrows. Every step is written out below the diagram.
What rewind can and cannot take back
Plan mode proposes before editing; each prompt takes a checkpoint; the Edit tool's changes are tracked but a Bash rm is not, so Restore code reverts the edit only and git is the real undo.
Reviewed on 17 October 2026 · Claude Code v2.1.301
Keys: ← → step · Home / End · K play or pause
You ask, Claude works through tools, and your files change. Claude Code also keeps checkpoints, and git sits beside them as a separate record.
In plan mode Claude reads files, can run shell commands to explore, and writes a plan. Edits to your source stay blocked until you approve it.
claude --permission-mode planPredict the next step You approve the plan and send the next prompt. What does Claude Code capture before Claude edits? (A checkpoint of your files · Nothing until you commit · A git commit)Every prompt that starts a turn creates a checkpoint of your code first. Approving the plan lets editing begin, and rewind can later return to this point.
Claude's Edit tool changes a file. Checkpointing tracks changes made through Claude's file-editing tools, so this one can be restored.
A Bash command such as rm, mv or cp changes files outside the checkpoint. Rewind does not track files modified by Bash commands.
rm file.txt mv old.txt new.txt cp source.txt dest.txtPredict the next step You rewind and choose Restore code. What happens to the file Bash deleted? (It comes back · It stays deleted)Press Esc twice or run /rewind, pick the prompt, choose Restore code. The Edit tool's change is reverted; the Bash deletion remains, because it was never tracked.
/rewind > Restore codeCheckpoints are session-level recovery, not version control. Commit before a risky step, so git can undo what rewind cannot.
git add -A && git commit -m "before the risky step"
What does Claude Code rewind restore, and what does it leave alone?
Claude Code captures the state of your code before each prompt you send that starts a turn, and it keeps file snapshots for the 100 most recent checkpoints in a session. Open the rewind menu with /rewind, or press Esc twice when the prompt box is empty. Pick a prompt, then choose Restore code and conversation, Restore conversation, Restore code, or one of two Summarize options. If no file edits were captured after that point, the menu offers only Restore conversation, the summarize options and Never mind.
Read more (2)Show less
The limits matter more than the features. Checkpointing tracks only edits made through Claude's file-editing tools, so a rm, mv or cp run through Bash cannot be undone by rewind. A subagent's edits are usually not captured either: rewinding restores only the files Claude had already edited in your conversation, and the subagent's other edits stay. Manual changes you make outside Claude Code, and edits from other concurrent sessions, are normally not captured. Symlinked and hard-linked files are skipped on restore, with a warning.
Checkpoints also expire. They are saved with the conversation, so /rewind still works after you resume a session, but Claude Code deletes a session's file snapshots in its retention sweep, by default about 30 days after the session last saved one. Rewinding to a checkpoint whose snapshots are gone can fail with No files were restored. The docs call checkpoints quick session-level recovery and tell you to keep using version control for permanent history.
How does plan mode keep a risky change reviewable?
Plan mode tells Claude to research and propose changes without making them. Claude reads files, runs shell commands to explore, and writes a plan, but does not edit your source, and edits stay blocked until you approve the plan. Enter it with Shift+Tab, with /plan before a single prompt, or with claude --permission-mode plan. When the plan is ready you choose how to proceed: start in auto mode, approve and review each edit manually, or keep planning with feedback. Ctrl+G opens the plan in your editor first.
Read more (1)Show less
Be precise about what plan mode promises. It blocks source edits, not every action: shell commands during planning are reviewed by the auto-mode classifier when auto mode is available, or prompt you when it is not. And in an interactive terminal session where bypass permissions are available, Claude Code does not enforce plan mode's blocks at all. Claude is still instructed to plan without editing, but an edit or shell command it attempts runs without prompting. If you run with permissions skipped, plan mode is a request, not a guard.
What is a safe order for a risky change?
Layer the tools by what each one can actually undo. Plan first, so the approach is reviewed before anything changes. Commit the working state, so git holds a point that no cleanup can lose. Then let Claude edit in small steps and use /rewind for mistakes in file edits, where it is fast and also restores the conversation. When the damage came through Bash, a subagent, or another session, rewind will not see it, and git is the way back. Choose Summarize from here when only the context is the problem: it compresses messages without touching files.
Read more (2)Show less
This repository shows the same layering in a place where rewind is no help. Its merge script writes six files through Bash, so no checkpoint covers it. The script defends itself by planning first, resolving every insertion point before writing, so either every edit is possible or nothing is touched. When that guarantee once failed, the recovery written down in the publishing skill is git status and git checkout, not rewind.
One more gate belongs at the end. Undoing is for mistakes you catch; verification catches the ones you do not. This repo's rule is to run the typecheck and the build before pushing, because the build fails on a registry mismatch that no reviewer would spot by eye.
The real config behind this lesson
Excerpts from the repository that builds and deploys this website, quoted as they are.
* Idempotent: a slug already in BLOG_POSTS_STATIC is skipped.
*
* node scripts/merge-blog-staging.mjs [--dry-run]
*
* Design note — why this is plan-then-write rather than validate-then-write:
* the previous version validated the staged CONTENT completely, then began
* writing, and resolved each insertion anchor at write time. When a constant
* moved module (REAL_IMAGE_SLUGS left blog-posts-static.ts), the third write
* threw after messages/*.json and the post registry had already been updated —
* a half-merged repo that a re-run would not fix, because by then the slug
* existed in en.json and got skipped. Anchors are now resolved during
* validation, so either every edit is possible or nothing is touched.A script that undoes nothing because it checks first. It resolves every insertion anchor during validation, so either every edit is possible or nothing is touched. It runs through Bash, so rewind could not restore it; planning before writing is how the script protects its own six files.
**The half-merge.** The merge script validates everything, then writes. Anchor
resolution happens at _write_ time, so a moved constant threw mid-write after
`messages/*.json` and `BLOG_POSTS_STATIC` were already updated. Re-running does
not recover — the script skips slugs it finds in `en.json` and considers the job
done. Recovery:
```bash
git status --short # see which of the six the aborted run reached
git checkout -- <those files> # revert only those; keep your component
# fix the anchor, then re-run the merge
```
Your component and staging folder are untouched by a failed merge, so only the
generated writes need reverting.The honest fallback. When the merge half-completed, the documented recovery is git status to see which files the run reached, then git checkout on those files only. Git, not a checkpoint, is the undo for a change made by a script.
**Always run `npx tsc --noEmit && npm run build` before pushing.** The build runs `assertBlogParity()` from `lib/blog-meta.ts` which fails if a blog post is registered in `BLOG_POSTS_STATIC` but missing from `BLOG_META` (or vice versa).Verification as the last layer. The build runs assertBlogParity(), which fails when a post is registered in one list and missing from the other. It catches a wrong change that both plan mode and rewind would have let through.
Mistakes that cost real time
Expecting rewind to undo a Bash command
Checkpointing does not track files modified by Bash commands. After rm, mv or cp, Restore code leaves the result as it is. Commit before you let Claude run commands that rewrite files.
Expecting rewind to undo other people's edits
Edits from a subagent, from another concurrent session, or made by you outside Claude Code are normally not captured. Rewind restores only the files Claude had already edited in your conversation.
Trusting plan mode with permissions skipped
In an interactive terminal session where bypass permissions are available, plan mode's blocks are not enforced. Claude is told to plan without editing, but an edit it attempts runs without a prompt. Use it as a workflow, not as a guarantee, in that setup.
A checkpoint that has aged out
Only the 100 most recent checkpoints keep file snapshots, and snapshots are deleted by default about 30 days after the session last saved one. An old restore can fail with No files were restored. Raise cleanupPeriodDays to keep them longer.
What I'd change here: git checkout can eat your own work
The half-merge recovery reverts the files the merge touched with git checkout. If those files held uncommitted changes of yours, the revert discards them too. Committing before running the merge would make that recovery safe. Nothing I found in this repo's instructions says to.
| Tool | What it protects | Where it stops |
|---|---|---|
| Plan mode | Holds source edits until you approve | Not enforced with bypass permissions available |
| Rewind: Restore code | Edits from Claude's file tools | Bash, subagents, outside edits |
| Rewind: Restore conversation | The chat, files stay as they are | Does not touch your files |
| git commit | Everything you committed | Uncommitted work |
Do it on your own machine
You need Claude Code and a scratch git repository with a committed file. You will plan a change, break it on purpose, and see exactly what rewind brings back.
Create two files and commit them, so git holds a clean starting point.
echo "one" > keep.txt && echo "two" > scrap.txt git add -A && git commit -m "start"Start in plan mode and ask for a small change. Read the plan, and approve it with manual edit review.
claude --permission-mode plan > add a second line to keep.txtIn the same session, send a new prompt asking Claude to edit keep.txt again and to delete scrap.txt with rm.
> change keep.txt to say three, then delete scrap.txt with rmPress Esc twice on an empty prompt, pick that last prompt, and choose Restore code.
/rewindCheck the result: keep.txt is back, scrap.txt is still gone. Then let git do what rewind could not.
git status --short git checkout -- scrap.txt
Three questions before you move on
Pick an answer to see why it is right or wrong. Nothing is saved or graded, so guess freely.
Answer in your head, then check
1.When should you pick Summarize from here instead of a restore option?Show the answer
Answer:When the problem is a long, noisy conversation rather than bad file changes. Summarizing compresses the messages from the chosen point to free context. It does not change files on disk, and the original messages stay in the session transcript.
2.Plan mode says no edits. Does that mean nothing can change on disk?Show the answer
Answer:No. It blocks source edits until you approve, but Claude can run shell commands to explore, and those are either reviewed by the auto-mode classifier or prompt you. With bypass permissions available in an interactive terminal, the blocks are not enforced at all.
3.Can you still rewind after closing Claude Code and resuming the session?Show the answer
Answer:Yes, checkpoints are saved with the conversation. But file snapshots are swept by default about 30 days after the session last saved one, and only the 100 most recent checkpoints keep them, so an old restore can fail.
Related deep dives on this site
Sources
Primary sources checked on the research date. Follow them for the current version.