How to undo Claude Code changes: /rewind, checkpoints, Git and file history

Short answer

Claude Code has an undo built in: checkpoints, opened with /rewind. It is a quick way back from a bad turn, mainly for changes Claude's file tools made in that session. It also has limits that Claude Code's own documentation spells out. This guide covers how /rewind works, what it leaves behind, and the two tools that pick up the rest: Git for code, and file history for the documents your agents write outside a repository. Everything below was checked against the current docs on November 12, 2026.

How do I undo Claude Code's last change?

Run /rewind, or press Esc twice when the prompt input is empty (Claude Code docs). The menu lists the prompts you sent in the session. Pick the point you want, then choose:

• Restore code and conversation: files and conversation both go back to that point.
• Restore conversation: the conversation goes back, your files stay as they are now.
• Restore code: the files go back, the conversation stays.
• Summarize from here or Summarize up to here: compress part of the conversation to free context. Files on disk don't change.

A few details that matter when you rely on it:

• Every prompt that starts a turn creates a checkpoint. Claude Code keeps file snapshots for the 100 most recent checkpoints in a session.
• Checkpoints are saved with the conversation, so /rewind still works after you resume a session.
• 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 "No files were restored". The cleanupPeriodDays setting keeps them longer.
• The two code options appear only when that checkpoint has tracked file changes.

To branch off and try a different approach while keeping the original session intact, the docs point to /branch or claude --continue --fork-session.

What doesn't /rewind undo?

The checkpointing docs list these gaps (Claude Code docs):

• Files that only Bash commands changed. Checkpoints track Claude's file editing tools. Once Claude has edited a file with those tools, /rewind also undoes later Bash changes to that file. A file that only shell commands touched, for example one rewritten by sed -i, a formatter or a script Claude ran, isn't tracked and stays as it is.
• Many subagent edits. A forked skill running in the foreground edits during your turn, so rewinding restores it. Other subagents, including forked skills running in the background (the default) and a background /code-review --fix, can leave edits that rewinding doesn't restore.
• Changes from outside the session. Edits you make by hand outside Claude Code and edits from other concurrent sessions are normally not captured, unless they touch the same files as the current session.
• Symlinked and hard-linked files. A restore skips them and warns Restored the code, but skipped N files.
• Messages sent mid-turn. A message you typed while Claude was working can be marked "No code restore"; restore from the prompt that started that turn instead.
• Old sessions. After the retention sweep, the snapshots are gone.

The docs sum it up themselves: checkpoints are for quick, session-level recovery, and for permanent history you should keep using version control such as Git.

How do I revert what /rewind can't reach?

If the files are in a Git repository, Git is the next layer:

• git status lists modified, staged and new untracked files, and git diff (plus git diff --staged) shows the line changes to tracked files, whatever made them: Claude, a shell command, a subagent or you. Files your .gitignore excludes don't show up.
• git restore <path> discards unstaged changes to a tracked file (git-restore). To go all the way back to the last commit, use git restore --source=HEAD --staged --worktree <path>. The discarded changes are gone, so look at the diff first. New files an agent created aren't touched; delete them by hand or with git clean (preview first with git clean -n; by default it refuses to delete unless you pass -f or -i).
• git stash -u sets uncommitted changes aside, including new untracked files, so you can get them back later with git stash pop (git-stash). Plain git stash leaves untracked files in place.

Git can only return you to a state someone committed, staged or stashed. A habit that makes it work well with an agent: commit before a prompt that will touch many files. Then you can see a bad run with git status and git diff and undo it with git restore --source=HEAD --staged --worktree <path> for the files you want back (plus git clean for new files), even if half of it happened through Bash.

What about files that aren't in Git?

Agents also write files that aren't code in a repository: specs, meeting notes, research, memory files, client reports, a team wiki, sometimes in a folder that several people's agents share. Checkpoints still cover what Claude edits with its file tools in your current session, but not what another session, another agent or a teammate wrote. Git helps only if those files live in a repository and someone commits them, and it can only take you back to what was committed, staged or stashed.

That layer needs a folder that keeps history by itself. BearDrive, which we make, is one option: it syncs a folder between teammates and agents and keeps the history of every file in it, whether the change came from Claude, a Bash command, another agent or a teammate on another machine, as long as BearDrive is syncing that device.

• bdrive log shows which account changed which file, when, and from which device.
• bdrive restore <file> puts the previous version back. bdrive restore --list <file> lists the versions, and bdrive restore <file> <version> picks one. The restore is recorded as a new change, so nothing is erased, and it reaches every synced device like any other edit.
• In the hub's History view, the changes from one agent session are grouped into a run card (the session id comes from the agent hook that bdrive init installs; Codex needs its experimental hooks turned on, and per-session detail is kept 30 days by default). Undo this run puts back every file that run touched: edited files return to their content from just before the run, and files it created are removed. The confirm lists every path before anything is written, including files someone changed after the run, which are reverted too. It needs write access on the project.
• Agents connected to a project through BearDrive's remote MCP server have history and restore tools, so you can ask the agent itself to put yesterday's version back (on BearDrive Cloud; a self-hosted hub has MCP off until you enable it).

Two limits to know. File history covers only files inside the synced folder and not ones excluded by .bdriveignore. And BearDrive records a version each time it syncs a change, so several quick writes between syncs can arrive as one version. For code, keep using Git; file history is for the files Git doesn't hold.

A routine that covers all three

• Before a big prompt: commit, so Git has a known-good point.
• Right after a bad turn: /rewind, then Restore code.
• If something is still wrong after the rewind: run git diff to find what Bash or a subagent changed. For files outside Git, check bdrive log or the run card.
• Prefer file tools to shell edits. If you want /rewind to cover more, add a line to CLAUDE.md such as "use the Edit tool to change files, not sed", because files changed only through Bash aren't tracked.
• Resuming an old session: checkpoints older than the retention window may be gone. Raise cleanupPeriodDays if you rely on them.

Which one should you use?

• Undo the last turn or two in this session: /rewind.
• Code changed by a shell command, a background subagent, another session, or a session past the retention window: Git.
• Docs, notes and memory outside Git, especially when several agents or teammates write them: a synced folder's file history, such as bdrive restore or Undo this run.