Sometimes a change is wrong. Sometimes you only realize after you accepted it. That’s not failure — that’s normal. The skill is knowing your way back before you click accept, not after.
The diff isn’t saved until you accept it. So Reject is your first and cheapest undo — and after you’ve accepted, Undo and
git restoreget you the rest of the way.
This is one of those habits that feels paranoid until the day it isn’t. Then it’s the only habit you trust.
Undo routes, smallest to biggest
0. Reject the diff.
The cheapest undo is the one you do before anything happens. When Claude proposes a change and the preview pane shows you a diff you don’t like — click Reject. The file never changes. There’s nothing to undo because nothing happened. This is the whole reason Claude proposes before it writes: the easiest mistake to fix is the one that never lands on disk.
1. Click Undo.
Accepted a change and immediately regretted it? Claude Code Desktop keeps the originals of files it touched, so Undo rolls the last change back. Fast, no typing, no git. This covers the common case — you accepted, you looked, you changed your mind.
You can also just say so in the chat:
Claude reads the conversation, knows what it changed, and proposes the inverse — which you then accept or reject like any other diff. Works best when the change is fresh and small.
2. git restore.
For files tracked in git, git restore <file> brings the file back to its last committed state — wiping out every change since, Claude’s or yours. This is the nuclear option. It’s fast, it’s surgical, and it works no matter how many turns ago the change was made, even across changes too tangled for Undo to unwind cleanly.
Full git workflow is its own level (Level 7 — Git the Claude way). For now, two ideas are enough:
- See which files have changed since the last commit.
- Throw out the changes in a file —
git restore <file>. Use carefully.
Picking the right route
The trade-off, roughly:
| Situation | Best route |
|---|---|
| Diff is still in the preview pane, looks wrong | Reject — it never lands |
| Just accepted it, single change, want it gone | Undo, or ask Claude to revert |
| Big change, multi-file, several turns back | git restore |
You don’t have to memorize this. Just notice the pattern: the earlier you catch it, the cheaper the undo. Reject costs nothing. Undo costs a click. git restore is the safety net for when both are too late.
The discipline that saves you
There’s one habit that turns “back out” from a panic into a one-liner: commit your work before big changes.
When Claude is about to do something with real blast radius — a cross-file rename, a refactor, anything touching more than a few files — make sure your current state is committed first. Then if the change goes wrong, git restore . undoes everything Claude did and leaves your prior work intact.
You’ll see this advice again in Level 5 (where it’s about safety) and Level 7 (where it’s about the full git workflow). It earns the repetition.
What’s next
You know how to back out. The closing skill in this level is the inverse: knowing when not to keep iterating, when not to back out, when to recognize that the change is done and walk away.