What are Claude Code checkpoints?
Claude Code checkpoints are automatic snapshots of your files that Claude Code takes before each prompt you send, so you can roll code and conversation back with /rewind or by pressing Esc twice. They cover edits Claude makes with its own file editing tools, and they are meant for quick undo inside a session, not as a replacement for Git.
The official checkpointing docs put it simply: Claude Code "automatically tracks Claude's file edits as you work, allowing you to quickly undo changes and rewind to previous states if anything gets off track." You do not need to turn anything on. Checkpointing is on by default.
How does checkpointing work?
Every prompt you send that starts a turn creates a new checkpoint. Claude Code captures the state of your code before that prompt and snapshots files before Claude edits them, so each checkpoint means "the code as it was before this request."
A few details matter in practice:
- History depth. Claude Code keeps file snapshots for the 100 most recent checkpoints in a session. Older snapshots are discarded when no remaining checkpoint needs them.
- Survives resume. Checkpoints are saved with the conversation, so you can still run
/rewindafter you resume a session withclaude --continueor/resume. - Retention. The retention sweep deletes a session's file snapshots, by default about 30 days after the session last saved one. Rewinding to a checkpoint whose snapshots are gone can fail with a
No files were restoredmessage. To keep them longer, raisecleanupPeriodDays, which defaults to 30. - Mid-turn messages. A message you type while Claude is still working is read inside the current turn, so it gets no checkpoint of its own. In the rewind menu it can be marked No code restore. To undo that part, pick the prompt that started the turn.
How do you rewind in Claude Code?
Open the rewind menu in one of two ways:
| Action | How |
|---|---|
| Slash command | Type /rewind (aliases /checkpoint and /undo) |
| Keyboard | Press Esc twice while the prompt input is empty |
If the input has text in it, double Esc clears the text instead and saves it to your input history, so Up brings it back later. The interactive mode reference lists this alongside the other shortcuts, and our Claude Code keyboard shortcuts guide covers the rest.
The menu lists the prompts you sent in the session. Select the point you care about, then choose an action:
| Option | What it does |
|---|---|
| Restore code and conversation | Reverts both files and the chat to that point |
| Restore conversation | Rewinds the chat to that message, keeps current code |
| Restore code | Reverts file changes, keeps the chat |
| Summarize from here | Compresses everything from this point forward into a summary |
| Summarize up to here | Compresses everything before this point, keeps later messages |
| Never mind | Goes back to the list without changing anything |
The two code options only appear when the selected checkpoint has tracked file changes to revert. After you restore the conversation or choose Summarize from here, the original prompt from that message goes back into the input field, so you can edit it and send it again. That is the fastest way to retry a request with better wording.
One quirk from the docs: rewound messages can return if you exit before sending your next prompt, because Claude Code saves the rewound conversation together with that prompt. Send something before you quit.
If you ran /clear earlier in the same Claude Code process, the menu also shows an entry labeled /resume <session-id> (previous session) at the top, which takes you back to the conversation from before /clear.
What does "Summarize from here" do?
The two summarize options do not touch files on disk. They shrink the conversation to free context window space, like a targeted /compact. The original messages stay in the session transcript, so Claude can still look up details later.
- Summarize from here suits a long debugging detour: keep your opening instructions intact and compress the noisy middle and end.
- Summarize up to here keeps recent messages word for word and compresses the older setup.
To steer the summary, highlight a Summarize option with the arrow keys and type instructions where the row reads add context (optional), then press Enter. Pressing the option's number key summarizes at once without instructions. A Summarized conversation marker then shows where the compressed messages were. For more on managing context, see the context window guide.
If you want to try a different approach while keeping the original session untouched, the docs point to /branch or claude --continue --fork-session instead of summarizing.
What do checkpoints not track?
This is the part to read before you rely on /rewind. The limitations section lists several gaps:
- Files changed only by Bash. Once Claude has edited a file with its file editing tools,
/rewindalso undoes later Bash changes to that file. A file that only shell commands changed is not tracked. If Claude ranrm,mv, a code generator or a migration, those effects stay. - Most subagent edits. Subagent edits are usually not captured in your session's checkpoints. A foreground forked skill edits your working tree during your own turn, so its edits rewind normally. For any other subagent, including background forked skills, rewinding only restores files Claude had already edited in your conversation.
- External changes. Edits you make in your editor and edits from other concurrent Claude Code sessions are normally not captured, unless they touch the same files as the current session.
- Symlinks and hard links. Restore skips tracked paths that are symlinks or hard links and shows a
Restored the code, but skipped N fileswarning. Dotfiles symlinked into a project and files pnpm hard-links into place fall into this group. Run/debugbefore restoring to log which paths were skipped. - Anything outside your files. Checkpoints cover file contents. A pushed branch, a sent message, or a changed database row cannot be rewound.
The docs end on a clear rule: checkpoints are "designed for quick, session-level recovery." Keep using Git for commits, branches and long-term history.
How do you turn checkpointing off or on?
Checkpointing is controlled by the fileCheckpointingEnabled setting, which defaults to true. It appears in /config as Rewind code (checkpoints), and toggling it there writes the key to your user settings.
{
"fileCheckpointingEnabled": false
}
To switch it off for one session only, set the CLAUDE_CODE_DISABLE_FILE_CHECKPOINTING environment variable. Whichever of the two turns it off, the other cannot turn it back on.
Non-interactive runs behave differently. In a claude -p run or an Agent SDK session, Claude Code ignores this key. The SDK turns checkpointing on with its enableFileCheckpointing option, and a bare -p run needs CLAUDE_CODE_ENABLE_SDK_FILE_CHECKPOINTING=true.
How should you use checkpoints day to day?
A pattern that fits the documented behavior:
- Commit before big asks. Checkpoints cover Claude's file edits, Git covers everything else. A clean working tree before a large refactor gives you both.
- Rewind instead of arguing. If a change went the wrong way, restore code and conversation to the prompt before it, then edit the restored prompt with clearer instructions. The bad attempt no longer sits in context.
- Use Restore code to compare ideas. Keep the conversation, revert the files, and ask Claude for a different approach with the reasoning still in view.
- Summarize long detours. After a messy debugging session, Summarize from here keeps your original brief and frees space.
- Use worktrees for parallel tries. For two approaches side by side, separate Git worktrees are safer than rewinding back and forth.
If you find yourself typing the same "start over, but this time..." prompt after each rewind, it is worth saving. Kipt keeps prompts like that as Markdown in a private GitHub repo you own, with {{name}} blanks for the parts that change and Cmd+K search to find them again.