Rewind to a checkpoint with /rewind

Back in the health session - adding GET /healthz beside GET /health in the payments service, the small TypeScript service this course uses as its running example - suppose a cleanup removes /health and leaves only /healthz. The new address still works. The older address that existing callers still use is gone, and the session is no longer tracking the requirement to keep both. This is a hypothetical wrong turn to reason through, not a claim about an edit your agent made.

A small deletion may need only a small correction. Claude Code saves a checkpoint of the session’s tracked edits before each prompt you send; /rewind lists them. If several follow-on edits depend on the mistaken removal, inspect the checkpoint before that turn instead. Enter /rewind; pressing Esc twice with an empty prompt also opens the menu. Choose the relevant point and read the available actions before confirming. The checkpointing reference documents what each restores.

Choose the state that needs to change

The three restoration choices answer different questions:

Choice	Tracked file edits	Conversation
Restore code	Return eligible files to the checkpoint	Keep the discussion
Restore conversation	Leave current files in place	Return to the selected point
Restore code and conversation	Return eligible files to the checkpoint	Return to the selected point

For the route-removal example, restoring only the conversation would leave /health missing. If you want to retain the explanation of the mistake while undoing eligible edits, choose code restoration. If the later discussion and edits both follow the wrong requirement, restoring both may be useful.

The code choices appear only when the checkpoint has tracked edits available to restore. Do not select a more distant checkpoint merely to find a button: it may also undo good work that followed it.

Check what came back

After a restoration, inspect the working tree yourself (these commands assume the Git baseline from the install lesson):

git status --short
git diff
git diff --cached

Open the file that registers the health routes. Check that the restored state is the one you intended, then run the relevant tests. If your health test file exists, use the focused command from the opening chapter, npm test -- tests/health.test.ts, followed by npm test. A success message from the rewind operation is not a test result.

If you restored the conversation too, supply the requirement again before continuing:

Keep both GET /health and GET /healthz. Before editing, inspect which
routes currently exist and explain the smallest change still needed.
Do not change unrelated behavior or report checks you have not run.

This makes the next action depend on the restored files. It also keeps a correction from becoming a request to redo work that already survived.

Know when the checkpoint is the wrong tool

Checkpoints cover eligible edits through Claude’s file-editing tools. Shell changes, external effects, and some other editing paths are outside that coverage. Rewinding does not undo a database request or reset Git history. Use the documented checkpoint limitations to determine whether the change you need is covered.

If the expected snapshot is absent or no files are restored, stop and inspect the diff. Preserve any useful work before choosing a Git recovery operation. Do not assume repeated rewind attempts can reconstruct an unavailable version.

Try the distinction on this case: the route implementation is correct, but a later discussion incorrectly claims it was never tested. Which restoration would alter the conversation without altering that code? Conversation-only restoration has that purpose; rerunning the test may be an even simpler way to establish the fact. The right move depends on what is wrong.

A checkpoint can help you retreat from a bad direction. Keeping two good directions available for comparison requires a different kind of preservation.