Claude Code rewind: what a checkpoint restores, and what it doesn't

What a checkpoint in Claude Code is

Anthropic's own description is short, and every later surprise comes out of it: checkpointing automatically captures the state of your code before each prompt you send that starts a turn, and it tracks the changes Claude makes with its file editing tools. So the unit of undo is a prompt, not a tool call and not a file. If you sent three prompts in one stretch and Claude edited six files, going back to the first of those prompts is one action, and it reverts everything after it.

Claude Code keeps file snapshots for the 100 most recent checkpoints in a session. They live under your Claude directory, in a per-session folder (~/.claude/file-history/<session>/), described as pre-edit snapshots of the files Claude changed, used for checkpoint restore. Discarding an older checkpoint deletes the snapshot files no remaining checkpoint references, with one exception: each file's first snapshot is kept, because the VS Code extension uses it as the baseline for a session's diffs.

Two things make checkpoints more durable than people expect, and one makes them less durable. More: they are saved with the conversation, so /rewind still works after you resume a session. Less: they are ordinary files in the retention sweep, which deletes a session's snapshots about 30 days after that session last saved one. The window is set by cleanupPeriodDays, which defaults to 30, takes a whole number of days with a minimum of 1, and refuses 0 outright. Anthropic suggests a large value such as 3650 when you want long retention.

Checkpointing is on by default, but it is not unswitched. The documented key is fileCheckpointingEnabled: true snapshots files before each edit so /rewind can restore them, false stops the snapshots, and it appears in /config as Rewind code (checkpoints), where toggling it writes the key to your user settings. One session can also be switched off with CLAUDE_CODE_DISABLE_FILE_CHECKPOINTING set to 1, which overrides the setting, and whichever of the two turns it off, the other cannot turn it back on.

How to open the rewind menu

There are two doors and they behave differently, which is the detail that confuses people first. Run /rewind, or either of its documented aliases, /checkpoint and /undo, and the menu opens. Or press Esc twice, which opens the same menu only while the prompt input is empty. If there is a draft in the box, the double press clears the draft instead and saves it to your input history, so you press Up to get it back after you have finished in the menu.

1. Open the rewind menu Run /rewind, or press Esc twice while the prompt input is empty. /checkpoint and /undo are aliases for the same command.
2. Pick the prompt to go back to The menu lists the prompts you sent during the session. Select the point you want to act on.
3. Choose what to restore Restore code and conversation reverts both, Restore conversation keeps your current files, and Restore code keeps the conversation. The two code options appear only when that checkpoint has tracked file changes to revert.
4. Or summarise instead of restoring Summarize from here compresses everything after the selected message, and Summarize up to here compresses everything before it. Neither touches a file on disk.
5. Read any skipped-files warning A restore can report Restored the code, but skipped N files, or No files were restored. Both mean part or all of the restore did not happen, and both name what to do next.

One place the menu is simply not there: Anthropic documents that rewind is unavailable in non-interactive mode, the -p run. For a usage-policy refusal in that mode its documented remedy is a rephrased prompt in a new session without --continue. That is the refusal's remedy, not a way to undo. A session Omniscio runs is that headless shape, and its own section says what that means for you.

The six actions in the menu

Pick a point and the menu offers six choices. They read like a diff of what is about to happen, so it is worth knowing which part of the session each one moves.

The two code options are conditional, and that condition is the menu telling you something. They appear only when the selected checkpoint has tracked file changes to revert; if no file edits were captured after that point, you get Restore conversation, the two summarize options and Never mind, with no code restore at all. After restoring the conversation, or after choosing Summarize from here, the original prompt from that message is put back in the input field so you can re-send or edit it. Summarize up to here leaves you at the end of the conversation with the input empty. With either summarize option, a Summarized conversation marker appears where the compressed messages were.

After you restore

The restore can look finished and then partly undo itself. If you exit before sending your next prompt, messages you rewound past can come back, because Claude Code saves the rewound conversation together with the next prompt you send. Either send a prompt before you leave, or if you have already exited, run /rewind in the session and pick the same prompt and Restore conversation again. Files you restored stay as the rewind left them either way.

A second surprise is /clear. If you cleared the conversation earlier in the same Claude Code process, the rewind menu carries an extra entry at the very top, labelled /resume <session-id> (previous session). Selecting it resumes the conversation that was active before the clear. The entry stays until you exit Claude Code or resume a different session — which means a /clear does not actually take your work away as long as you stay in the same process.

Summarise, or branch

Summarizing is the odd one out in that menu: it does not change files on disk, and the original messages stay in the session transcript, so Claude can still refer to the details. To steer what the summary keeps, highlight a Summarize option with the arrow keys and type your instructions where the row reads add context (optional), then press Enter; picking it with its number key summarises straight away with no instructions.

Anthropic's own framing is that a summary is a targeted /compact, and it keeps you in the same session. If what you actually want is a different approach without losing the original, that is a different command: /branch, with an optional name, or claude --continue --fork-session. A branch copies the transcript and switches the running process to write to it, and the original stays unchanged on disk and in the picker, where you return with /resume <original-name> or its ID.

What rewind does not cover

This is the section to read before trusting an undo. Checkpointing tracks the files Claude changed with its file editing tools, and nothing else, so a rewind is narrower than the word "undo" suggests.

The Bash row is subtler than "shell commands are not tracked". Once Claude has edited a file with its editing tools in your conversation, /rewind undoes changes a Bash command makes to that file afterwards. And under each prompt the menu counts changes to files Claude had already edited, whatever made them — so a prompt where only a shell command touched such a file still lists file changes. What never gets tracked is a file whose only editor was the shell.

That boundary has moved recently, which is worth knowing if you read older advice. In 2.1.309 Anthropic changed sed -i to get the standard Bash prompt and run as written rather than as a simulated file-edit preview, and said plainly that like other Bash edits it is no longer restored by /rewind. The same release fixed the opposite annoyance: the rewind list had been showing "No code changes" for a turn that did change checkpointed files through /code-review --fix, a subagent or a shell command. Reports filed by users follow the same line. One describes auto mode steering the model to make its edits through Bash and heredocs, after which no prompt offered Restore code at all; another describes the same effect more briefly, with code changes invisible to the CLI and /rewind unable to restore them [G2, G7].

Messages typed mid-turn are their own trap. In the menu, a message you typed while Claude was still working can be marked No code restore, because it has no checkpoint of its own. To undo the file edits Claude made after that message, do not select the message; select the prompt that started the turn and choose Restore code or Restore code and conversation. That reverts the whole turn's edits, including the ones made before your message arrived.

Links are skipped deliberately. Checkpointing does not rewind symlinked or hard-linked files: a restore skips any tracked path that is a symlink or hard link and reports a skipped-files warning, leaving those files with their current contents. Config files a dotfile manager symlinks into your project, and files pnpm hard-links into place, both fall in this bucket. To see which paths were skipped, turn on debug logging with /debug before you restore — the log at ~/.claude/debug/<session-id>.txt names each path as the restore runs. On macOS or Linux you can also look for them directly with find . -type l for symlinks and find . -type f -links +1 for hard-linked files.

Two more absences are worth stating plainly, because people go looking for them. There is no documented per-file restore: every code action works on the set of tracked files at the prompt you picked. And there is no documented way back past the 100 most recent checkpoints in a session. Older snapshots are what the retention rules remove.

None of this makes checkpoints a bad tool. It makes them a session-level one: Anthropic describes them as designed for quick, session-level recovery, and says to keep using version control for commits, branches and long-term history.

The two restore messages

A code restore can come back incomplete, and Claude Code says so in one of two messages. Both are documented, and both mean a file you expected to change did not change. They are not the only errors a session can print, so the Claude Code error messages guide is the place to start from a message rather than from this topic.

The documented skip reasons are three: the path is, or became, a symlink, hard link or other non-regular file; its directory changed since the checkpoint; or its backup cannot be safely read. Skipped paths keep their current contents. Before 2.1.216 the old behaviour was worse in a quieter way — /rewind wrote and deleted through links at tracked paths and did not report a partial restore at all.

No files were restored has two ordinary causes. The backups may be gone: the retention sweep removes a session's snapshots about 30 days after it last saved one, so a session resumed after that still lists its checkpoints but cannot necessarily restore them. Or the backups never arrived in this copy: forking a session with --fork-session or /branch copies the original's backups into the fork, and a backup Claude Code could not copy (a full disk, for instance) is missing there.

The documented recoveries are unglamorous, which is the honest answer. If the backups are gone, running /rewind again fails the same way, so undo it another way: ask Claude to reverse its edits, or restore the files from version control. If Claude Code could not write to or delete a file, fix what blocks the write, such as permissions, and run /rewind again. For next time, raise cleanupPeriodDays.

Two user reports are worth carrying here rather than in a theory section, because they describe what the messages can feel like from the outside. One report says Claude Code said it could not restore, then changed the files anyway and deleted files created since, with the conversation not rewound, and about 20 hours of work lost in a project that was not under git [G4]. Another says a rewind silently put the session back into the permission mode that was active when the selected prompt was sent — including, in one direction, bypass permissions for a process that was never launched with a bypass flag [G3]. Both were open when this page was checked. They are reports, not a description of every build, and the practical reading is the same either way: keep the work in version control, and check the mode indicator after a rewind.

Checkpoints against git

The two tools answer different questions, and the difference is not speed. A checkpoint is a snapshot of the files Claude edited, taken at a prompt boundary and living inside one session. Git is a record of the whole tree that you decide to make, name, and share. Anthropic's own line is that checkpoints are for quick, session-level recovery and that version control remains the home of permanent history and collaboration.

The practical consequence: a checkpoint is something you reach for in the next ten minutes, and git is what you reach for after that. If the work matters past today, commit it, and if something a shell command did is not in a checkpoint, the commit is not a nicety, it is the only copy.

Rewind in an Omniscio session

Omniscio does not add a checkpoint or rewind control of its own: a search of its own source finds no setting and no button that snapshots or restores a session's files. The checkpoints belong to the Claude Code process that ran the session and live in that Claude directory, which means the data is there — but reaching the menu from Omniscio is a different question, and the answer is no.

Omniscio drives each Claude Code session headlessly, one stream-json turn at a time, and that is the non-interactive shape in which Anthropic documents rewind as unavailable. So the menu this page describes is a feature of a Claude Code session in a terminal. In an Omniscio session there is nothing to press: the panel has no rewind view, and the terminal's menu never renders. To use it, open the session in a terminal — the conversation is saved with the session, so /rewind there still lists its prompts.

Typing it anyway is worth knowing about. Omniscio recognises /rewind in its composer and answers with a pointer to its own diff viewer, saying it will not auto-rewind file edits the way /rewind does; /checkpoint and /undo are not among the commands it recognises, so those two reach the model as ordinary text.

What the app does own is the deliberate half of undo. Its diff viewer shows what a session changed, file by file and hunk by hunk, and lets you accept or reject each one; rejecting a whole file discards that file's current changes after a confirmation. That is a discard of what is on disk now, not a rewind to an earlier point in the conversation, which is why it also cannot bring back something a shell command overwrote.

Where the two meet is isolation. Omniscio can run a session in its own copy of the project — a git worktree on its own branch, in a <project>-worktrees folder beside your project — and every isolation switch is off by default. It can be switched on for one session, one project or the app-wide default. One exception exists: a session on an engine whose tools run outside Claude Code's guardrail hooks (Gemini, Grok, Antigravity, OpenCode, Hermes, Pi, Kimi Code and DeepSeek Harness) is isolated by default in a git repository, and the project and app-wide defaults cannot turn that off, though a per-session choice still can. With isolation off, a session edits your real folder, so a rewind and a discard both land there; with it on, they land in the copy.

Omniscio is a desktop app for running several agent sessions side by side. Any model, any harness — Claude Code, Codex, OpenCode, Devin, Pi, and Hermes all supported. The Free plan is a real plan, with 8 projects and 10 agents running at once, and Pro is $20/month or $192/year. One boundary worth knowing before you reach for a cap: the per-session spend cap limits sessions billed to a metered API key or to Omniscio credits, and a subscription session on a Claude Pro or Max plan is never spend-capped.