How to undo Claude Code changes

Last updated: 5 October 2026

Claude Code changed something you did not want: a file rewritten, a file deleted by rm, a dependency installed. There are three ways back, and each one restores different things. This page says what each one covers, so you can pick the right one before you need it.

1. Claude Code's own rewind

Claude Code keeps a checkpoint before each prompt that starts a turn. Run /rewind, or press Esc twice when the prompt input is empty, pick a message, then choose to restore the code, the conversation, or both.

What it covers, from Claude Code's checkpointing documentation:

Edits made with Claude's file editing tools in the current session.
Snapshots for the 100 most recent checkpoints in a session; they are deleted about 30 days after the session last saved one.
Checkpoints are saved with the conversation, so /rewind still works after you resume a session.

What it does not cover, in the documentation's words: "Checkpointing does not track files modified by Bash commands." So a file Claude removed with rm, moved with mv, or changed through npm install or a script does not come back. Edits by most subagents, changes made outside Claude Code and symlinked files are not restored either. The documentation's own advice: checkpoints are "Not a replacement for version control."

2. git

If you committed before you asked Claude for something, git can take everything back: git restore . for changed files, git clean for new ones (look with git clean -n first). git stash keeps your own uncommitted work out of the way while you do it.

Its limits:

It only knows what you committed. Work since the last commit, yours or Claude's, is not in it.
Plain git stash leaves out untracked files (-u adds them) and files your .gitignore excludes, such as .env (-a adds those).
Claude can run git too. A git checkout -- . or git reset --hard in a turn throws away uncommitted work, and git cannot give it back.

3. turnslip

turnslip is a Claude Code plugin. It snapshots the project at the start and at the end of every turn and compares the two, so a file changed by a shell command counts as much as one Claude edited. One line under each reply says what changed; /turnslip:undo takes the last turn back.

It restores every file the turn changed or deleted, and removes the files it created, including those a command like rm, mv or npm install touched.
It never overwrites a file you changed since the turn: that file is kept and named.
The undo is a turn of its own, so it can be undone too. With Pro, /turnslip:undo 3 takes back an earlier turn.

Its limits, said plainly:

Paths your .gitignore excludes are never read, so they are never restored. A .env Claude deleted stays deleted.
A write outside the project folder is flagged, not restored.
A database migration, a git push, a deploy or a global install is listed as not undone; no file undo can take those back.
On the first turns in a new or very large project, before its index is built, a turn can run in light mode: Claude's own edits stay undoable, but shell changes are not tracked yet, and the slip says so.
Files over 5 MB are not kept, and each project keeps its last 50 turns.

Which one to use

Commit before a big request, whatever else you use. For a quick step back in the same session, /rewind also rewinds the conversation. When Claude runs commands, and you want to see what changed before you decide, turnslip covers the shell changes the other two can miss. They work side by side.