Auto-accept mode makes Claude Code fast. It also makes it possible for an agent to make five wrong edits before you notice the sixth one is broken. Checkpoints exist to fix the asymmetry: instead of trusting a single "undo" keystroke to work like it does in a text editor, Claude Code silently snapshots your working tree before every tool call that changes it, so "go back" is always available even after the agent has moved on to three more edits.
Most people find out checkpoints exist by accident, mid-panic, after a refactor goes sideways. Here's how the system actually works, what /rewind restores and what it doesn't, and how it fits next to permission modes as a second, independent layer of protection.
What a Checkpoint Actually Captures
Before Claude Code executes any action that modifies your filesystem — a file edit, a file creation, a deletion — it records a checkpoint of the affected files' prior state. This happens automatically, with no configuration and no prompt; it is not something you opt into per session, and it is not the same thing as a git commit. Checkpoints are local, session-scoped snapshots, not history you push anywhere or that persists once the session ends.
Critically, a checkpoint captures file state, not the conversation alone. This is the detail that separates it from just re-reading your chat history to see what changed — the checkpoint is a restorable snapshot of the actual bytes on disk at that point in time.
The /rewind Command
/rewind opens a list of prior checkpoints in the current session, each tied to the message or tool call that triggered it. Pick one and Claude Code restores the affected files to their state at that point. You can rewind file changes only, conversation context only, or both together — useful when the agent's code was fine but its understanding of the task drifted, or the reverse.
This is the piece people miss: rewind isn't purely a filesystem operation. Rewinding the conversation resets what the agent "remembers" about the task alongside the code, which matters when a bad edit came from a bad premise a few turns back, not just a bad execution of a correct one.
What Checkpoints Don't Protect Against
Checkpoints are scoped to the current session and to changes Claude Code itself made through its tools. They don't cover:
- Shell commands with side effects outside the filesystem — a command that calls an external API, sends a message, or modifies a remote resource isn't undone by rewinding local files, because there's nothing local to restore.
- Changes from a previous session — checkpoints don't persist indefinitely across every session you've ever run; they're a working buffer for the session in front of you, not a permanent audit log.
- Anything outside the working directory scope Claude Code is tracking — files it never touched were never snapshotted, so there's nothing to roll back to if something else modified them.
The practical rule: checkpoints protect against "the agent wrote something wrong to a file," not against "the agent did something irreversible in the outside world." For that second category, permission mode and hooks are the actual safeguards — checkpoints are a local safety net under them, not a replacement.
Checkpoints vs. Git
The two overlap in purpose — both let you go back — but they solve different problems. Git commits are deliberate, named, and yours to curate; they're the record you want to keep and share. Checkpoints are automatic, unnamed, and session-local; they exist so an in-progress task can be undone before you'd ever think to commit anything. Treat checkpoints as the safety net under a single working session, and git as the actual history you care about once a change is verified and worth keeping. Committing frequently during agent-driven work doesn't become less valuable because checkpoints exist — it just means a bad edit rarely needs anything more than a quick rewind before you'd otherwise reach for git.
Checkpoints vs. Permission Modes vs. Hooks
These three layer rather than duplicate each other. Permission modes decide whether an action happens at all — ask first, auto-accept, or bypass. Hooks can block a specific action outright regardless of mode. Checkpoints assume the action already happened and give you a way back afterward. This is precisely why auto-accept mode is viable in the first place — it's tolerable to let edits through without a prompt each time specifically because a bad one is one /rewind away from undone, not because bad edits stopped happening.
When to Actually Use /rewind
- A multi-file refactor went off the rails — rewind past the point where the approach diverged, rather than manually reverting file by file.
- The agent's understanding of the task was wrong from the start — rewind both code and conversation, then re-explain the task instead of patching a plan built on a bad premise.
- You approved an edit too fast in auto-accept mode and want it undone without breaking your flow to manually diff and revert.
- Comparing two approaches — checkpoint before trying an alternative implementation, rewind back if it doesn't pan out, without needing a git branch for something this short-lived.
Common Mistakes
The most common failure isn't rewinding wrong — it's not rewinding at all because people don't know the feature exists and instead manually reconstruct file state from memory, or worse, ask the agent to "undo that" and get a fresh edit that approximates the old state rather than an exact restoration. The second most common mistake is treating checkpoints as a substitute for committing real work to git — they expire with the session, and a change worth keeping needs a real commit regardless of how convenient the local undo felt in the moment.