How to undo changes in Claude Code: /rewind and git

Practical information about working with Ailoot is available in the documentation.

What is undo in Claude Code, and why aren't three levels enough?#

I enabled /rewind in my first week of using Claude Code, when it broke my project's auth logic in two prompts. I rewound, exhaled, and carried on. A month later, another situation came up: I was writing a schema migration, Claude helped, I committed, switched branches—and realized I had forgotten a necessary step. /rewind didn't help—the session was already different. git checkout to the previous commit helped. A month after that, I accidentally told the agent, “roll everything back to the last push,” and it ran git reset --hard, wrecking three hours of work. git reflog saved me—the hashes of the destroyed commits were still there.

Those three stories are three levels of protection that work differently, catch different errors, and are all needed. This guide explains each level with its commands, limitations, and examples, plus shows how to configure a project in advance so Claude doesn't take it down the first time.

3 levels of undo—what and when:

Next, we’ll go through each level—what exactly to do, the pitfalls, and how to configure things so there's nothing to undo because nothing broke.

How do you invoke /rewind: command or Esc-Esc?#

After every response, Claude automatically takes a snapshot of all files it edited in that session. Snapshots are stored in ~/.claude/file-history/{sessionId}/ and retained for up to 30 days. Snapshots are incremental—only the differences between states are saved, not the entire file. By default, up to 100 snapshots are stored per session. This means that in most real projects, you have a complete history of all of Claude's changes throughout the workday at any given moment.

To open the rewind menu, press Esc twice when the input field is empty:

[user-input is empty]
> _

[press Esc, Esc]

Rewind to which message?
  1. Create a migration for the User table          (3 files changed)
  2. Add the lastLoginAt field                      (1 file changed)
  3. Rewrite the authorization logic                (5 files changed)
  ...

If there is text in the input field, the first double press of Esc clears it and saves it in Up history. This is useful when you've already started typing and realize you need to rewind. A quote from Anthropic's official documentation:

The /rewind command does the same thing—it opens the menu. There is an alias, /checkpoint, that leads to the same place. Which method is more convenient is a matter of habit. I use Esc Esc—it's faster and doesn't take my hands off the keyboard.

6 modes in the Rewind menu: which one should you choose, and when?#

Choose a point in the list, and you’ll land in the actions menu. Six items, each doing something different.

Complete table of modes:

The Summarize up to here feature appeared in Claude Code v2.1.139-v2.1.142, released May 11–15, 2026, week 20:

The difference between Restore and Summarize is fundamental. Restore returns to a previous state, undoing everything that happened after the selected point. Summarize doesn't undo anything; it only compresses—the original messages remain in the session transcript for reference, but only the summary remains in active context. Use restore when you want it to be “as if this never happened.” Use summarize when you want to “keep it, but not take up context space.”

After Restore conversation or Summarize from here, the original text of the selected prompt returns to the input field—you can edit it and send it again. After Summarize up to here, the input field is empty, and you remain at the end of the conversation.

What changes does /rewind NOT undo?#

This is the main limitation people run into: /rewind shows a green check mark and says “rewind successful,” but the project is still broken because Claude touched more than just files. Let’s look at the three cases.

1. Bash commands are not tracked. If Claude runs rm file.txt or mv old.txt new.txt in a turn, those changes won't be included in the checkpoint. Anthropic's documentation states explicitly:

This means that if Claude deletes, moves, or copies a file on its own using the bash tool, /rewind won't restore everything. git checkout or restoring from backup can help, but that takes more than pressing two keys.

2. External edits aren't caught. If you manually open a file in VS Code and edit something, or a second Claude session changes the same files in parallel, the first session can't see those changes. A checkpoint snapshot is taken when Claude finishes a turn in the current session. What happens between turns is outside its responsibility.

3. Operations outside files are not covered at all. A Prisma migration applied through npx prisma migrate dev changed the database schema—/rewind won't undo it because the database is outside the project's file system. A force-push to origin/main is the same: the commit went to the remote server, and the checkpoint won't bring it back. A remote API call that charged money or deleted a record can be undone only through the API's own mechanisms.

Rule: If a task affects anything outside the project files—database migrations, git push, remote APIs—prepare a separate rollback strategy for each external effect. /rewind is only the local file history within the current session.

/rewind vs git: how are they different, and why do you need both?#

Anthropic's documentation states this pairing directly:

The differences in one table:

The pairing is simple: whenever you reach a state where “this is working, and I don't want to lose it,” make a git commit. Between commits, rely on /rewind—it's instant, doesn't require a commit message, and doesn't clutter git history with intermediate states. When the work is done, commit—preferably a meaningful, atomic one.

Why doesn't one /rewind cover the whole task?#

Undo is one case of context engineering. Manage session context (when to commit, when to press /rewind, what rules to put in CLAUDE.md) and you get a predictable Claude that doesn't destroy the project or lose work.

Why is git reset --hard dangerous when you ask Claude to “roll back”?#

A request to “save the current state and roll back to the last push” can lead to these commands:

git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix"  # saved uncommitted changes
git reset --hard 35eb731                                                # destroyed commits d63695e..882e618

The first command was correct—it saved the uncommitted changes in the stash. The second was destructive: it rewrote the branch to commit 35eb731, and all commits between it and 882e618 became orphaned. By default, orphaned commits remain in .git/objects/ until git gc runs, which usually happens automatically within two weeks. But if you didn't know what to do at that moment, time was already working against you.

The logic is simple: in natural language, “roll back,” “go back,” “restore,” “revert,” and “undo” mean “look back” or “return to a safe place.” They don't mean “destroy history.” The git reset --hard command destroys it—it rewrites the branch and removes commits from those reachable through HEAD. A safe alternative is git checkout <commit>, which creates a detached HEAD and lets you view the old state without touching branches.

The main practical takeaway is to git commit the current state before any substantial task, especially before refactoring multiple files. One commit turns any Claude screw-up into one git checkout . command without losing work.

How does git reflog save you after a destructive reset?#

After a destructive reset, run git reflog right away:

git reflog

The output looks like this:

35eb731 HEAD@{0}: reset: moving to 35eb731
882e618 HEAD@{1}: commit: middleware refactoring complete
d63695e HEAD@{2}: commit: leaveRemove method finalized
1f9c8a3 HEAD@{3}: commit: tracker enter/leave disabled
35eb731 HEAD@{4}: pull origin main

HEAD@{1} through HEAD@{3} are those very “destroyed” commits. They haven't disappeared from git's local object store; they've simply become inaccessible through the branch. To restore them:

# Create a branch from the last “destroyed” commit
git branch recovered-work 882e618

# Or switch directly
git reset --hard 882e618

After that, the branch once again contains all the history up to the disaster.

Reflog limitations:

1. Local only. The reflog is stored in .git/logs/HEAD; it isn't on the remote repository. If you force-push and then delete your local repo copy, the reflog goes with the folder.
2. 90 days by default. Older entries may be removed by git gc. You can configure it with git config gc.reflogExpire 200.days.ago.
3. Doesn't cover what was never in HEAD. If a commit was only in the stash and the stash was destroyed, the reflog will show only the stash's latest state, not its internal history.

Rule for the team: never run git gc --aggressive right after a disaster. First investigate with reflog and recover; do everything else afterward. And never delete the local repository clone until you're sure everything you need has been pushed.

How do you protect a project from destructive git commands through CLAUDE.md?#

The vulnerability is that Claude has no protective context by default. It interprets “roll back” as git reset --hard because technically that's a valid method. Put the protection in CLAUDE.md—the project's system prompt file.

Minimal rule (insert into your CLAUDE.md):

## Git Safety Protocol

- NEVER run destructive git commands (push --force, reset --hard, checkout ., restore ., clean -f, branch -D) unless I explicitly request these actions. Taking unauthorized destructive actions is unhelpful and can result in lost work.
- When I say "roll back", "go back", "restore", "revert", "undo" - interpret as REVIEW commands: use `git log`, `git diff`, `git checkout <commit>` (creates detached HEAD), or `git stash` (preserves changes).
- ALWAYS ask for confirmation before ANY command that:
  - Changes HEAD position to a different commit on a branch
  - Modifies commit history
  - Could lose uncommitted work
  - Includes flags --hard, --force, --aggressive
- Before any destructive command, output a numbered comparison:
  - SAFE: use `git checkout <commit>` to view temporarily
  - DESTRUCTIVE: use `git reset --hard` to permanently destroy
- Wait for my explicit choice before executing.

Extended rule for the team (add to the repository root's CLAUDE.md):

## Git Workflow Rules

- Commit at each working milestone. Before a WIP commit, run `git status` and `git diff`, stage only explicitly reviewed named files with `git add -- path/to/file`, then inspect the staged diff before committing. A timer is a reminder to review, not permission to stage the entire working tree.
- Never use `git add .` or `git add -A` for commits by Claude. Only specify files by name, after `git status` + `git diff`.
- Before `git push --force` to main—stop and ask me. In feature branches, force-push cautiously, only if you're sure I'm willing to lose the previous version.
- When resolving merge conflicts, never choose "ours" or "theirs" immediately—show me both versions first, then I'll decide.
- `.gitignore` must contain `.env*`, `.claude/personal/`, `node_modules/`, `dist/`. If they're missing, add them.

After adding these blocks, the next phrase “roll back to the last push” would lead to this response:

I see 3 uncommitted files and 4 commits ahead of the last push. Two options:

1. SAFE: create a view-last-push branch through git checkout <last-push-hash>—I’ll preserve all the work, but temporarily show the state of the push.
2. DESTRUCTIVE: git reset --hard <last-push-hash>—I’ll permanently destroy 4 commits and the uncommitted changes. They can be restored only through git reflog within 90 days. Which do you choose?

That’s half a minute of conversation instead of four hours of lost work.

What are the 5 ways to undo in Claude Code, and how do you choose the right one?#

The scenario “Claude broke it, I need to restore it urgently” proceeds from the bottom up this ladder. Always start at level 1.

Level 1. /rewind—instant undo within a session.

Press Esc Esc or type /rewind. Choose the point before the break. Choose a mode (usually Restore code and conversation). A second later, you're back in the past and can start over. Covers 80% of “Claude did the wrong thing” cases.

Level 2. git checkout .—undo all uncommitted changes.

git diff                    # first see what actually changed
git checkout .              # undo all uncommitted changes in all files
# or selectively:
git checkout -- path/to/file.ts   # only one file

Useful when /rewind didn't work (for example, Claude touched files through bash) or when you need to undo outside the session history. All changes that weren't committed will disappear permanently. If you might regret that, run git stash first (see level 2.5).

Level 2.5. git stash—put your changes on the shelf.

git stash save "might still need this"
# return to a clean state (without changes)
# ...
# if you change your mind—restore from stash:
git stash pop

A good compromise between “lose forever” and “leave as is.” The stash remains local until explicitly cleared.

Level 3. git checkout <commit>—return to an old commit without losing history.

git log --oneline               # find the hash of the right commit, e.g. abc1234
git checkout abc1234            # detached HEAD—view without changing anything
# like the state? create a branch from it:
git checkout -b recovery abc1234
# return:
git checkout main

This is a safe “temporary return.” Detached HEAD doesn't change the branch; your current work in main (or whichever branch you were on) remains intact. If you want to work with this state, create a branch.

Level 4. git reset --hard <commit>—move the branch back to a point.

⚠️ Destructive. Commits ahead of the specified hash become orphaned.

git reflog                                  # note the hash of the current state
git reset --hard abc1234                    # rewrite the branch
# found a mistake? return through reflog:
git reset --hard HEAD@{1}                   # to where you were before the reset

Use only if you're sure you don't need the commits ahead. And always check git reflog BEFORE reset so you know where to return if you change your mind.

Level 5. git reflog + recovery—a catastrophic scenario.

Someone (Claude, you, a colleague) has already run git reset --hard or force-push and wiped out the work. What do you do?

git reflog                                          # look for the last hash before the disaster
git branch recovered HEAD@{N}                       # create a branch from it
git checkout recovered                              # switch to it
git diff main                                       # compare with the current state
git checkout main && git merge recovered            # restore into main, if you're sure

If the reflog has already been cleared (after 90 days by default), the last resort is git fsck --lost-found, which will show dangling commits in .git/objects/. This is nearly archeology, but sometimes it works.

Rule for choosing a level:

How do you protect a project so there's nothing to undo?#

Rule 1. Commit every 30 minutes.

Don't wait until “the task is done.” Commit any intermediate step that works. Commit messages can be anything; the main thing is that Claude (or you) can return to a working state with one git checkout command.

# at the beginning of a task
git status                        # inspect all staged and unstaged paths
git diff                          # review the changes
# Replace this example path with the actual file you reviewed.
git add -- path/to/file.ts
git diff --cached                 # verify exactly what will be committed
git commit -m "wip: starting User schema migration"

# after 30 minutes (or after the first working iteration)
git status
git diff
git add -- path/to/file.ts         # actual reviewed path, not a directory wildcard
git diff --cached
git commit -m "wip: User schema is ready, migration applied locally"

# at the end of the task—a meaningful commit
git reset --soft HEAD~2           # combine the three wip commits into one
git commit -m "feat(auth): add lastLoginAt field to User table"

If you add a PostToolUse reminder, keep the same review and explicit-path staging rule. Do not turn a timer into an unchecked auto-commit: unrelated edits or already staged files can otherwise enter the commit.

Rule 2. Minimum .gitignore.

These lines are required in the project root:

# secrets
.env
.env.local
.env.*.local

# local Claude Code settings (not pushed to the team repository)
.claude/personal/
.claude/sessions/
.claude/file-history/

# dependencies and build
node_modules/
dist/
.next/
build/

I keep the .claude/personal/ folder for my own experiments and notes, which must not be included in the shared repository. The .claude/sessions/ and .claude/file-history/ folders are Claude Code's local storage; they don't belong in the repository, take up a lot of space, and are tied to a specific machine.

Rule 3. Experiments on a separate branch.

If the task is large (refactoring 10+ files, migrating to a new database, rewriting a module), don't do it on the main branch:

git checkout -b experiment/auth-rewrite
# work, commit every 30 minutes
# if it works:
git checkout main
git merge experiment/auth-rewrite
# if it doesn't:
git checkout main
git branch -D experiment/auth-rewrite     # delete the branch
# that's it, the main branch is intact

This simple habit turns “Claude trashed the project” into “Claude trashed one branch, I deleted it, and we start over.”

Rule 4. Before dangerous operations, use git tag.

Before a database migration, a large refactor, or a dependency update, create a tag:

git tag pre-prisma-migration-v2
# work
# something went wrong:
git reset --hard pre-prisma-migration-v2
# or just take a look:
git checkout pre-prisma-migration-v2

A tag is a named pointer to a commit that you won't lose even through reflog cleanup.

What's next: how does undo fit into context engineering?#

These three levels of undo are the infrastructure for one skill: knowing how to restore a state when it breaks. That skill is narrow by itself. But combined with other context engineering tools, it becomes something more.

Plan Mode doesn't let you write code immediately—first comes the plan, then confirmation, then execution. This is preventive undo: you don't write what you'll later have to undo because the plan was reviewed in advance. Read more in the guide to Plan Mode in Claude Code.

CLAUDE.md sets rules that Claude respects by default, including the Git Safety Protocol we covered above. This is preventive protection against destructive commands.

The Second Brain gives Claude memory about the project between sessions—it knows what code you have, what the business logic is, and what agreements were made earlier. The more memory, the less likely it is to do the wrong thing.

Skills and subagents are your methodology in code. If the correct git workflow is built into a Skill, no subagent will run git reset --hard without confirmation.

And all of this together is Context Engineering. Manage context before the prompt, not during it. Read more in what is context engineering.

Undo is the last line of defense. Plan Mode + CLAUDE.md + Second Brain + Skills are the first four. When they are set up, undo becomes rare and quick. When they're not, it becomes a daily ritual.

Undo begins where planning ends.

Open Ailoot.