Claude Code Checkpointing: Rewind Risky Changes

Checkpointing is a Claude Code feature that automatically snapshots your project before each change the agent makes. Each checkpoint captures both the files as they were and the point in the conversation that produced them, so you can return to a known-good state later. It gives you an instant, session-scoped undo for agent edits without any manual setup.
Open the rewind menu by pressing the Escape key twice in quick succession, or by typing the rewind command. You will see a list of recent checkpoints, and selecting one previews what returning to it will do. Claude Code then asks whether to restore the code only, the conversation only, or both together.
No. Checkpoints are tied to your session and can expire or disappear when it ends, and they do not cover manual edits or files changed by bash commands. Treat checkpointing as a fast, temporary undo for agent mistakes and keep committing to git for any state you actually want to preserve.
Yes. When you rewind, Claude Code lets you choose to bring back the code only, the conversation only, or both. Restoring the conversation without the code lets you keep edits you liked while stepping back to an earlier point in the discussion, and the reverse lets you discard edits while keeping what you have discussed.
Not reliably. Checkpointing tracks edits Claude Code makes through its own editing tools, so files rewritten by a shell command it runs, edits you make by hand in another editor, and anything outside the tracked workspace can fall outside a checkpoint. A rewind may not restore those changes, which is why git remains your source of truth.

Key Takeaway
Claude Code checkpointing automatically snapshots your project before each edit, so you can rewind to any earlier state when a change goes wrong. Press Escape twice or run the rewind command, then choose to restore code, the conversation, or both. It is an instant undo for agent mistakes, not a replacement for git commits.
Letting an agent edit your code fast is exhilarating until the moment it refactors the wrong module, deletes a working function, or takes the plan in a direction you never wanted. Undoing that by hand is slow and error-prone, and the undo shortcut in your editor only reaches the one file you happen to have open.
Claude Code checkpointing exists for exactly this moment. It records the state of your project before each change the agent makes, so you can jump back to a known-good point in a single step. This guide explains how checkpoints are created, how to rewind, and where the feature stops so you do not lean on it for something git should do.
A checkpoint is an automatic snapshot Claude Code takes before it applies an edit. You do not have to ask for one; the session records them as it works, building a timeline of states you can return to. Each checkpoint captures both the files as they were and the point in the conversation that produced them.
That pairing of code and conversation is what makes rewind useful rather than just another undo stack:
There are two ways into the rewind menu. Press the Escape key twice in quick succession, or type the rewind command. Either opens a list of recent checkpoints, and picking one previews what returning to it will do before you commit to it.
When you rewind, Claude Code asks what you want to restore. You can bring back the code only, the conversation only, or both together, which lets you keep a useful discussion while throwing away the edits it led to, or the reverse.
Rewind is the safety net that makes bold prompts affordable. Because a bad edit is one keystroke from being undone, you can let the agent attempt an ambitious change, watch the result, and rewind instantly if it misfires, instead of over-specifying every guardrail up front.
Rewind shines whenever the cheapest path forward is to abandon the last stretch of work rather than repair it. A few recurring situations fit that shape.
Checkpointing tracks the changes Claude Code makes through its own editing tools. It is not a general-purpose version control system, and it does not see everything that happens in your working tree. Treat it as a fast, session-scoped undo, not as your source of truth.
That distinction matters most around changes the feature does not capture. Files rewritten by a shell command the agent runs, edits you make by hand in another editor, and anything outside the tracked workspace can fall outside a checkpoint, so a rewind may not restore them the way you expect.
Checkpointing is not a substitute for git. Checkpoints are tied to your session and can expire or disappear when it ends, and they do not cover manual edits or files changed by bash commands. Keep committing to git for anything you actually care about keeping.
Rewind is strongest when it sits alongside the habits that already keep agent work under control, not when it replaces them.
Checkpointing lowers the cost of letting an agent try things, because any change it makes is a keystroke away from being undone. Learn the double-Escape rewind, decide deliberately whether to restore code, conversation, or both, and keep committing to git for the states that matter. Used together, they let you move fast without fear of losing work.