Claude Code Checkpoints and /rewind

There is a specific moment that everyone who works with a coding agent recognises. You come back to the terminal, read the last three messages, and realise the agent went somewhere you did not want it to go — four files ago. The code technically runs. It is also not what you asked for, and you no longer remember exactly what the files looked like before.

/rewind exists for that moment. It is one of the most useful things Claude Code added in 2026 and one of the least understood, mostly because people assume it is a git feature wearing a different name. It is not, and the difference is the whole point.

What checkpointing actually does

Claude Code saves a checkpoint automatically before it edits files — you do not turn it on and you do not ask for it. Each checkpoint captures the state of the code at that point in the session, paired with the conversation that produced it.

That pairing is the interesting part. A checkpoint is not just a snapshot of your files; it is a snapshot of your files and the agent's understanding at the same instant. Which means you can restore either one independently, and the three options you get solve genuinely different problems:

• Code and conversation. A full rollback. The files go back and the agent forgets the detour ever happened. Use this when the whole line of work was wrong.
• Conversation only. The files stay as they are, but the agent's context winds back. This is the one people never think of and it is quietly the most useful: when the agent has talked itself into a bad mental model but the code it wrote is fine, you can wipe the reasoning without losing the work.
• Code only. Files revert, the conversation stays. Useful when you want the agent to remember what it tried and why it failed, then attempt it differently on a clean tree.

How to open it

Two ways. Type /rewind, or press Esc twice. The double-Esc is worth putting into muscle memory, because the times you want it are the times you are already reaching for Esc to interrupt the agent mid-run.

You get a list of checkpoints from the current session. Pick one, pick what to restore, and you are back. No staging, no stash, no commit-message guilt.

Why this is not just git

The obvious objection is that git already does this. It does not, and the gap matters in practice:

• Granularity. Nobody commits before every edit. The agent checkpoints before every edit. When a thirty-turn session goes wrong, git gives you one commit from an hour ago; checkpoints give you the exact turn.
• Conversation state. Git has no concept of the agent's context. git checkout can put your files back, but the agent still believes everything it believed five minutes ago — including the wrong thing it convinced itself of. That is usually the actual problem.
• No ceremony. Rewinding does not touch your branch, your index, or your reflog. You are not making history you then have to clean up before opening a PR.

The correct mental model is that checkpoints are session-scoped undo and git is project-scoped history. They are complementary, and you want both. Commit at the points a human would care about; rewind at the points the agent got confused.

The limits, stated honestly

Checkpoints are scoped to the session and to the file edits the agent made. That leaves some real gaps you should plan around:

• Side effects outside the file tree do not roll back. A database migration that ran, a dependency the agent installed, a file it deleted outside the working directory, an API call it made — rewinding the code does not rewind any of those.
• Your own manual edits sit awkwardly alongside it. If you edited a file in your editor while the agent was working, a code restore can take your change with it.
• It is not a backup. Long-lived work still belongs in commits. Treat rewind as an undo buffer, not as version control.

The practical rule: rewind freely for anything the agent wrote, and commit before anything irreversible — migrations, deploys, large-scale refactors. If you run several agents at once, that discipline matters more, not less; we wrote about keeping that manageable in running multiple Claude Code sessions.

Where rewind fits with plan mode

Plan mode and rewind attack the same problem from opposite ends. Plan mode stops a bad approach before it touches your files. Rewind undoes one after it has. If you find yourself rewinding several times in a session, that is a signal to front-load more: a clearer brief, plan mode for anything touching more than a couple of files, and a CLAUDE.md that removes the guesswork. Rewind is a safety net, and a safety net you hit constantly means the wire is too low.

The part nobody mentions: you have to be there

Every benefit of checkpointing depends on catching the wrong turn reasonably soon after it happens. Rewinding one turn is trivial. Rewinding twenty turns means you also throw away the fifteen good ones that came after the bad one, because the good work was built on top of it.

Which makes the real skill not rewinding but noticing. The sessions that go badly wrong are almost always the ones where the agent ran unattended for a long stretch while you were in a meeting, in another window, or making coffee — and then you came back to forty turns of work built on a decision you would have rejected at turn three.

A workflow that uses it properly

• Commit before you start a substantial task, so git is your floor and checkpoints are everything above it.
• Stay reachable while the agent runs. Notifications beat polling, and they turn a twenty-turn rewind into a one-turn rewind.
• When something feels off, open /rewind immediately rather than trying to talk the agent out of it. Arguing with a bad context usually costs more turns than resetting it.
• Reach for conversation only more often than you think. Bad reasoning with good code is the most common failure, and it is the cheapest to fix.
• Commit as soon as a task is genuinely done, so the next session starts with a clean floor.

The shift in how this feels

Before checkpointing, letting an agent edit files was a small act of faith every time. You either supervised every change or you accepted that untangling a bad run might cost more than doing the work yourself. That tension is the real reason a lot of people kept agents on a short leash.

Rewind removes most of it. The cost of a wrong turn drops to a few keystrokes, which means you can let the agent attempt more ambitious things. The remaining cost is not the mistake — it is the time between the mistake and you noticing. That part is still yours to solve.