/rewind deleted my code — how to recover it and prevent itYou rewound, and edits you wanted are gone. This page explains exactly what /rewind can and cannot touch, how to get your work back right now, and the one free hook that makes any future accident recoverable.
An earlier version of this page said the picker opens on the most destructive action and runs it with no preview. That was wrong, and it is worth being precise about, because the wrong version makes you guard against the wrong keystroke. The maintainer's closing comment on anthropics/claude-code#64615 says the picker opens with “(current)” highlighted, so a stray double-Esc followed by Enter is a no-op, and selecting an older checkpoint leads to a screen headed “Confirm you want to restore…” that previews what will happen. The person who filed the issue agreed: the first Enter is not the problem — the second one is.
So the accident this page helps with is not a slip of the escape key. It is choosing an older checkpoint on purpose, past a confirmation, and discovering afterwards that it took more than you expected — or that something you needed was never in the checkpoint store at all. That second case is the common one, and it is covered below.
/rewind can not touchClaude Code's own documentation is explicit about the boundary, and it is the boundary that saves you:
“Checkpoints are designed for quick, session-level recovery. … Think of checkpoints as ‘local undo’ and Git as ‘permanent history’.”
— Claude Code docs, Checkpointing › Not a replacement for version control
/rewind restores from Claude Code's internal checkpoint store. It does not rewrite your git history. Anything you committed — even once — is still in your repository and is fully recoverable. The same docs also list two limits that work in your favor here:
rm, mv, cp, build steps, or any shell command are outside checkpointing — so /rewind did not revert them.Only files edited through Claude's own file-editing tools in this session, after the checkpoint you selected, get reverted.
If you committed at any point, your work is there. /rewind cannot rewrite commits or the reflog.
git reflog # every HEAD position, newest first
git log --all --oneline # all commits, including detached ones
git stash list # anything you (or a hook) stashedRecover a single file from a known-good commit without disturbing anything else:
git checkout <commit-sha> -- path/to/file.tsOr, after confirming the SHA in git log, restore the whole tree (this discards current working changes — be sure first):
git switch -c recovered <commit-sha> # safe: lands the state on a new branchIf you were running a backup hook before the accident, the lost content is on disk outside the checkpoint store:
git reflog / git log — if auto-checkpoint.sh was active, every edit was committed automatically; the version you lost is one of those commits..claude/recycle-bin/ — if file-recycle-bin.sh was active and the loss involved a deleted file.Changes from shell commands, other sessions, or manual edits were not part of the checkpoint, so the rewind did not undo them. Run git status and open the files — that work is likely still in your working tree.
If the lost edits were made by Claude's edit tools, were never committed, and no backup hook was running, then the post-checkpoint version of those files may be genuinely unrecoverable — checkpointing keeps only the before-edit states it captured, not a redo stack. The fix for next time is below, and it is one line.
The durable protection is to make sure every edit also reaches git — the layer /rewind cannot rewrite. cc-safe-setup ships auto-checkpoint.sh for exactly this: a PostToolUse hook that creates a lightweight commit after every Edit/Write. After that, any accidental rewind is fully recoverable with git log and git cherry-pick.
# clone & install the free hooks (MIT, runs locally, nothing leaves your machine)
npx github:yurukusa/cc-safe-setup@latestThree hooks in the kit cover the data-loss family that /rewind sits inside:
auto-checkpoint.sh — auto-commit after every edit, so a rewind is always recoverable from git (#34674).uncommitted-work-shield.sh — auto-stash before destructive git commands (reset --hard, checkout --, clean -fd) so the other common way to lose uncommitted work is caught too.file-recycle-bin.sh — intercepts rm and copies the file to .claude/recycle-bin/ first.Note on scope: a hook cannot add a confirmation step inside the /rewind menu itself — slash commands aren't tool calls, so there is no hook event to intercept. The honest, durable defense is the recoverable git layer above, not a fake "are you sure" prompt.
Want the whole safety net, not just rewind?
cc-safe-setup is a free, MIT-licensed set of Claude Code hooks for irreversible-operation and data-loss protection — destructive command guards, git safety, secret guards, and the checkpoint hooks above.
Get cc-safe-setup on GitHub →Survives /rewind? | What |
| ✓ Yes | Anything committed to git (history & reflog are not rewritten) |
| ✓ Yes | Files changed by shell commands (rm/mv/cp/builds) — not tracked |
| ✓ Yes | Manual edits & other-session/hook writes — normally not captured |
| ✗ At risk | Uncommitted edits made by Claude's edit tools after the chosen checkpoint |
Facts about checkpoint behavior are quoted from the official Claude Code Checkpointing docs; the reported pain is issue #64615. This page does not run any code or collect anything. Part of cc-safe-setup — free, MIT-licensed Claude Code safety hooks. Last updated 2026-06-03.