Skip to content
Mastering Claude

Home / When things go wrong

When things go wrong9 minApplication

Undoing and recovering a change

To undo Claude Code's last action within the current session, the checkpoint menu opened by /rewind now comes before Git, which remains necessary for everything this system does not track: a change made by a bash command, a sub-agent's background edit, or a file linked by a symbolic or hard link.

Undoing Claude Code's last change within the current session no longer goes, first and foremost, through Git. The checkpoint menu, opened by /rewind or a double press of Escape when the input line is empty, offers three distinct choices: restoring the code and the conversation, the conversation alone, or the code alone, to an earlier point in the same session. Asking Claude Code in natural language to undo its last change triggers this same mechanism. This route costs less than a detour through Git for a still fresh action: no commit to hunt down, no branch to recreate, just an immediate return within the same session.

What the checkpoint system does not track

The official documentation itself bounds its own scope: this system is not a replacement for version control, and for a permanent history or work done with others, it recommends continuing to use Git, for commits, branches and long term history. Three concrete limits come on top of this, each corresponding to work Claude Code did not do itself with its own editing tools. Changes made by a bash command, rm, mv or cp, are not tracked: only edits that went through Claude's file editing tools are. Edits made by a background sub-agent also escape restoration. A file linked by a symbolic link or a hard link is ignored during a restore.

Git remains the tool for what checkpoints ignore

git restore removes an uncommitted change from the working directory. git reflog finds any earlier position of HEAD, including a commit that seems lost after a bad reset.

git reflog
# shows every position of HEAD, the most recent first
git branch securite <hachage-retrouve>
# recreates a branch from a recovered state, without touching the current branch

Recreating a branch from a hash found in the reflog remains preferable to a git reset --hard: the reset overwrites the current state, the safety branch keeps it alongside without losing anything. Checking the reflog costs one command, a badly aimed reset can cost a whole afternoon spent hunting the work back down by hand. This same distinction between going back and permanent erasure comes back, applied to an entire conversation rather than a single file, in loops, polluted context and restarting.

Figure 1

From an unwanted change to a safety branch

01
Unwanted change
A recent Claude Code fix needs undoing, in code, in conversation, or both.
02
Checkpoints first
/rewind or a double Escape opens the menu and restores to an earlier point in the same session.
03
Limit reached
A bash command, a background sub-agent edit, or a linked file escapes this restoration.
04
Reflog checked
git reflog finds the position of HEAD before the change, even after a commit that seemed lost.
05
Safety branch
A branch recreated from this hash keeps the current state alongside it, instead of overwriting it with a destructive reset.
The sequence places the checkpoint menu before Git for the session's last action, then switches to Git for everything this menu does not track.
Calibrate it yourself

A developer notices that a change applied by Claude Code five minutes earlier breaks a test. He opens the checkpoint menu with a double press of Escape and selects the option that restores the code alone, to the moment before that change.

Write, in one sentence, what this situation establishes, and in one sentence what it does not establish.

What to remember
  • The checkpoint menu, opened by /rewind or a double Escape, restores the code and the conversation, the conversation alone, or the code alone, to an earlier point in the same session.
  • The official documentation presents this system as a complement to Git, not a replacement, for permanent history and work done with others.
  • Changes made by a bash command such as rm, mv or cp, edits made by a background sub-agent, and files linked by a symbolic or hard link all escape restoration by checkpoints.
  • git restore removes an uncommitted change from the working directory, git reflog finds any earlier position of HEAD, including a commit that appears lost.
  • Recreating a branch from a hash found in the reflog keeps the current state alongside it, whereas a git reset --hard overwrites it.
Do this now

Before any git reset --hard on your repository, run git reflog, spot the hash of the state you want to keep, and create a safety branch from that hash before continuing.

Check the source

Every datable claim in this lesson links here to the public text behind it. A source that does not open proves nothing.