Undo without panic
Esc-Esc, rewind, and what git still owns
Three edits into a session, Claude Code starts changing a file you never meant for it to touch. Your first instinct is to type three more corrections trying to talk it back into place. There was a faster way the whole time: press Escape twice, and go back to before it wandered.
16 min · You'll know exactly what a session's undo can and can't save you fromYou'll learn the real undo built into every Claude Code session, exactly what it can and can't take back, and why git still matters even after you've learned to rewind.
Before you start
Complete Run a first safe session first; this lesson is the safety net for when that first safe session drifts anyway.
Remember from Run a first safe session?
Last lesson, you learned to isolate risky work in a separate worktree before it starts. Without scrolling up, what's the relationship between that habit and this lesson's rewind?
Show one good answer
A worktree is prevention, set up before risky work starts, so your main project stays untouched no matter what happens. Rewind is the cure, used after something already went sideways, to get the current session back to a known-good point. You want both: isolate what you can ahead of time, and know how to undo what still goes wrong anyway.
The idea
A session going sideways is not an emergency. It is the single easiest thing in Claude Code to take back.
| Session rewind (Esc-Esc) | Git | |
|---|---|---|
| Undoes | Claude Code's own file edits, and the conversation | Any committed change, to any file, from any source |
| Lasts | Only for this one session | Permanently, across sessions and restarts |
| Cannot touch | Shell-command changes, or edits from other programs | Anything you never committed |
| Use it for | "That last stretch went wrong, take me back" | "I want to return to this exact state next month" |
Use both. Rewind is the cure for a session gone sideways; git is the memory that outlives the session.
The real mechanic: press Escape twice, with an empty prompt box, and Claude Code opens a rewind menu, a short list of earlier points in this session you can jump back to. Pressing Escape once with something still typed just clears your draft, so the empty-box part matters. From that menu you can restore the conversation and the code together, the conversation alone, or the code alone, back to that point.
What it actually undoes, said plainly: rewind tracks edits Claude Code made through its own file-editing tool. It does not track changes from shell commands it ran, like rm or mv, and it does not track edits any other program made to your files. If a step in your session ran a command that touched files directly, rewind may not be able to put those back. This is not a small footnote, it is the one thing worth remembering before you trust it.
Session undo and git are two different safety nets, not one. Rewind lives inside this one Claude Code session, gone the moment the session ends. Git, your project's own saved history, the record of every version you have chosen to keep, is your project's permanent history, the one that survives closing the terminal, restarting your computer, or coming back next week. Committing just means telling git "save this version," a habit worth building even if Claude Code does it for you when you ask. Rewind is for "that last stretch went wrong, take me back." Git is for "I want to be able to return to this exact state a month from now." Use rewind for the first, and keep committing to git for the second. Neither one replaces the other.
Worked example. Three edits into a session, Claude Code starts refactoring a file you never asked it to touch.
Claude Code v0.0.0
Sonnet (200K context) · Claude Pro
~/project
Refactoring UserSettings.tsx to use the new hook pattern...
Rewind menu: 3. Before refactor of UserSettings.tsx 2. Added toggle handler 1. Session start Restore conversation + code to point 3? (y/n)
Instead of arguing it back into place, you press Escape twice, see the point right before it wandered, and restore the conversation and code together. You are back to the known-good state, and you re-brief it with the boundary you forgot to name the first time.
It is also completely normal to just throw a session away. Many practitioners restart a good share of their sessions, not because something broke, but because starting clean was faster than untangling where it drifted. That is routine, not a sign you did something wrong.
Rewind is the undo for the session you are in right now. Git is the memory that outlives it. Know which one you need before you need it.
Watch
You type this
Claude Code just started refactoring a file that has nothing to do with what I asked. Press Escape twice, show me the rewind menu, and restore the conversation and code together to the point right before it started that refactor.
Claude does this
Claude Code opens the rewind menu with a short list of earlier points in the session. You pick the one right before the unwanted refactor, restore both the conversation and the code, and the session is back to a known-good state, with nothing about the wandering edit left behind.
Why this works
- Press Escape twice
an empty prompt box is what opens the rewind menu; the same key once, with text still typed, would only clear your draft.
- restore the conversation and code together
naming both means you get back the exact state, not just the chat history with the unwanted file changes still sitting there.
Your turn
What actually gets that file back
Rewind only tracks edits made through Claude Code's own file-editing tool. A deleted-by-command file is a different kind of problem.
Show one good answer
not rewind, at least not on its own: a shell command's deletion isn't something rewind tracks. Your real backstop here is whatever you've committed to git, which is exactly why session undo and git are two separate safety nets, not one.
On your own
Think of one real Claude Code session that went sideways recently, even a small one. Write three lines: what went wrong, whether rewind alone would have fixed it or you needed git too, and one habit you'll change (committing more often, or reaching for rewind sooner) because of it.
- I described a real session, not a hypothetical one
- I correctly judged whether rewind alone would have covered it
- I named one concrete habit I'll actually change
Write your own
Loading your workbook…
When this breaks
- Breaks when you trust rewind to undo a shell command's side effects, because it only tracks Claude Code's own file edits.
- Breaks when nothing was ever committed to git, because a closed session takes its rewind history with it.
You can now
You can open the rewind menu and choose what to restore
- You can say what rewind does not cover, specifically
- You can tell session-level undo apart from git's permanent history
- You do not treat restarting a session as a personal failure
Try it from memory
Pulling this out of your own head now is the part that actually moves it into long-term memory. Re-reading just feels like it does.
Without scrolling up, name the keybinding that opens the rewind menu, and the one category of change it cannot undo.
Tap to see one good answer
Escape twice, with the prompt box empty. It cannot undo changes made by shell commands, like rm or mv, or by any program other than Claude Code's own file-editing tool. That gap is exactly why git still matters even after you've learned to rewind.
Key takeaways
Esc-Esc opens a real undo for this session's conversation and code. It cannot undo shell commands or other programs, and it disappears when the session ends, so git still owns your permanent history.
- Escape twice, with an empty prompt, opens the rewind menu.
- Rewind only tracks edits Claude Code made through its own file-editing tool, not shell commands or other programs.
- Session undo is temporary. Git is permanent. Use both, for different reasons.
- Restarting a session that went sideways is routine, not a mistake.