# Recovering when it goes wrong

Checkpoints make mistakes cheap to undo, /clear beats a third correction, and a few debugging habits find the cause when the tool itself misbehaves.

## Mistakes are cheap if you can go back

Every prompt that starts a turn captures the file state first. These are checkpoints, and they are why you can let Claude try something without fear.

`/rewind` opens the menu. Its aliases are `/checkpoint` and `/undo`, and pressing `Esc Esc` on an empty prompt does the same. The menu offers five choices:

- restore code and conversation
- restore conversation only
- restore code only
- summarize from here
- summarize up to here

The split matters. If Claude edited the right things but you took a wrong turn in the discussion, restore the conversation only. If the conversation is fine but the edits went bad, restore the code only.

Rewinding is also the cheap way to change direction. The guide prefers `/rewind` to abandoning a path, because it returns to a prefix that is already cached, unlike compaction.

> **Know what checkpoints do not cover**
Bash-only file changes are not tracked unless Claude already edited that file with its edit tools in the session. Subagent edits are generally not restored by rewind, so use git for those. Checkpoints cover the 100 most recent, and are cleaned up about 30 days after last save. Git is still your real safety net.


**Question:** Claude's code edits are good, but the conversation went down a wrong path. Which rewind choice fits?

- Restore code only
- Restore conversation only
- Delete the repository
- Restore code and conversation

**Answer:** Restore conversation only. Keeping the good edits and rolling back only the conversation preserves the work and fixes the direction.


## Correct early, then reset

The cheapest correction is the first one. As soon as you see Claude heading the wrong way, press `Esc`. It interrupts and keeps the work done so far, then you redirect.

Stop correcting at two. The guide's advice is exact: after two failed corrections, `/clear` and write a better prompt instead of a third correction. A long thread of failed attempts is itself in the context, and it is re-read on every turn. The old mistakes keep influencing the next try.

`/clear` is free, and it also separates unrelated tasks, so the old history is not re-read each turn. It labels the old session for `/resume`. After a `/clear`, the rewind menu offers a `/resume <session-id> (previous session)` entry to get back until you exit.

Remember that CLAUDE.md edits and this reset arrive together: the new text loads after `/clear`.

## Debugging habits

When the problem is Claude's answer, the tools above are enough. When the problem is the tool, the docs give a short order of checks.

- `/doctor` checks installation, settings, extensions and context usage, and proposes fixes. `claude doctor` runs from the shell.
- If settings do not apply, hooks do not fire, or MCP does not load, try `claude --safe-mode` first, to see whether a plugin, MCP server or hook is the cause.
- Compare `/context` with a `/clear`ed baseline to see which rows (messages, MCP, memory) fill the window.
- `--debug-file <path>` writes logs to a file and turns debug on.
- Vague searches slow Claude down. Name the directory or file type.

> **Change one thing at a time**
Safe mode is useful because it removes many variables at once. Then add them back one by one, so you learn which one was guilty.


**Question:** Claude has failed to fix the same bug after two corrections. What does the guide recommend?

- A third, firmer correction
- /clear and a better prompt
- Switch to bypass mode
- Ignore the bug

**Answer:** /clear and a better prompt. A pile of failed attempts stays in the context and is re-read each turn. A fresh start with a better prompt is cheaper.


> **Practice the undo**
In a throwaway branch, ask for a small edit, then press `Esc Esc` and restore the code only. Watching the files change back once makes later experiments feel safe.