Claude Code checkpoints and /rewind: your safety net for risky edits

You let Claude Code refactor for thirty minutes, glance at the screen, and the test runner burns red. Three files are broken, you no longer remember exactly which prompt touched what, and git diff shows a wall of changes. Checkpoints exist for exactly this moment. Every prompt you send automatically creates a snapshot of your files, and with /rewind (or Esc twice) you jump back to any point in the session. I use this ten times a day now and do not want to work without it.

Here are the ten steps for using checkpoints properly. They save you the reflex of committing every minute and still let you experiment aggressively.

Step 1: Understand what is tracked (and what is not)

Claude Code creates a checkpoint of your files on every prompt, but ONLY for files touched via Claude's edit tools. If Claude runs a bash command like rm file.txt or mv old.txt new.txt, that is invisible to checkpoints. External changes you make in the editor are outside too.

Meaning: checkpoints are not a git replacement. They are a session undo for AI edits. Git stays responsible for the long-term history. Once that is clear, you avoid the classic beginner mistake of "let me just rewind that" when an npm install broke something. Bash stuff stays broken.

Step 2: Open the rewind menu

Type /rewind or press Esc twice when the prompt line is empty. Careful: if there is still text in it, Esc first clears the input field (the text goes into the history, get it back with arrow up). Only on the second empty Esc does the menu open.

The rewind menu lists every prompt you have sent in the session, from top (old) to bottom (new). Arrow up and down scrolls through the points, enter selects one.

Step 3: Restore code and conversation (the hard reset)

The default option. Rolls back both your files and the chat history to the state before the selected prompt. The original prompt lands back in the input line, you can edit it and send it again.

That is my default for "I sent Claude in the wrong direction ten minutes ago". One click, everything back, different prompt, carry on. Saves 20 minutes of discussing with Claude where it misunderstood something.

Step 4: Restore code (files back, keep the chat)

You want the code back because a refactor broke something, but the discussion was actually good. Take "Restore code". Files jump back, the chat stays completely intact.

Useful when Claude has already recognised the mistake in the discussion ("ah I imported the module wrongly") and you do not want it to roll the change up again from zero. Files back, then say "ok please fix the import error but leave everything else".

Step 5: Restore conversation (chat back, keep the code)

The mirror variant. You want to cut away the chat history because you accidentally stuffed it full of side quests, but the code state should stay. A good choice when Claude philosophised for thirty minutes about the wrong design pattern and you want to keep the last working state of the files.

Effectively that is also a form of context reset without losing the workspace.

Step 6: Summarize from here vs. summarize up to here

The two summarize options are the killer feature when your context window is filling up. They replace parts of the chat with an AI-generated summary and thereby create room.

• Summarize from here: everything BEFORE the selected prompt stays in detail, the selected prompt and everything after it get condensed into the summary. Useful when you had a wild debug session and only need the initial plan in detail.
• Summarize up to here: the mirror image. Everything BEFORE the selected prompt gets condensed, from there on it stays in detail. Classic setup reset: early setup stuff becomes the summary, your last 20 minutes of productive work stay untouched.

Both variants keep the original messages in the session transcript, so Claude can still reference them if needed. That is more targeted than /compact, which simply flattens everything.

Step 7: Know the fork trick for experiments

If you want to try an alternative WITHOUT touching the running session, rewind is the wrong choice. Take fork: claude --continue --fork-session. That creates a branch of the session, the original session stays untouched.

Practical pattern: when I am unsure whether an approach works, I fork the session and try the approach in the fork. If it does not work, I throw the fork away and carry on in the original. If it does, I merge the files over manually (or make it the new main session).

Step 8: Use the 30-day persistence

Checkpoints live for 30 days and survive session restarts. If you end a session on Monday and come back in on Wednesday with claude --continue, all the checkpoints are still there. You can jump back days later to the point where test A was green.

Mandatory routine: when you reach a genuinely critical state (tests green, deploy ready), make a git commit anyway. Checkpoints are a convenience feature, not a backup system. 30 days go by fast when you get ill or take a holiday.

Step 9: Combo with plan mode and subagents

Where checkpoints get really strong: in combination with plan mode. Plan mode lets you sign off a step-by-step plan before execution. If Claude then takes a wrong turn during execution, you rewind to the point BEFORE the approval, correct the plan, and let it run again.

The same goes for subagents. If a subagent builds something silly down in the depths, it is easier to rewind the main prompt than to try repairing the subagent output backwards.

On plan mode read our Using plan mode properly playbook, on the subagent setup Your first subagent in 30 minutes.

Step 10: Avoid anti-patterns

Three mistakes I often see and that you want to avoid:

1. Using rewind as a git replacement. If you run bash commands for file operations (mv, rm, cp), you cannot rewind that. Nor manual edits in the editor. For everything except Claude file edits you still need git.
2. Forgetting that external changes are not tracked. If a second Claude Code session works on the same repo in parallel (I do that often with different sub-tasks), session A does not see session B's edits in its own checkpoint. Worst case you rewind a file that session B is currently filling.
3. Using summarize too aggressively. Both summarize options condense information. What Claude considers "unimportant" for the summary is not necessarily unimportant for you. If you have just made a subtle architecture decision, do not summarize straight over it. Better /compact with explicit instructions, or a fork.

What next

Once checkpoints have sunk in, the next logical step is the clean context workflow. Look at Managing the context window in Claude Code, where we go deeper into /compact, session forks and the difference between local recovery and permanent history.

If you want to use checkpoints in a team setup (several devs on the same repo), combine it with our Claude Code in a team playbook. It says how you share CLAUDE.md cleanly so sessions stay consistent.

Source

Specifications verified against the official documentation:

• Checkpointing reference
• Interactive mode (keyboard shortcuts)
• Session forks