Checkpoints, undo and rewind.

Code can go back in two dimensions: workspace files and conversation history. Choose the dimension that matches the mistake. Checkpoints supplement version control; they do not reverse every side effect. This guide covers CLI 0.9.0.

#Check whether snapshots are available

Checkpoints are enabled by default for a trusted workspace with Git available. They use a separate snapshot store, without making commits or resets in your project's Git history. /status reports whether capture is available and why it is off. Capture failures do not necessarily stop the task.

Snapshots respect ignored, protected, secret, and excluded files; nested repositories and special files are not a complete-backup escape hatch. Limits and retention also apply. Set "checkpoints": { "enabled": false } in user agent.json to disable them for future sessions.

#Undo the latest exchange

Wait for the active turn to finish or stop it, then use:

/undo

Code previews the exchange and available file changes. When a file checkpoint is available, you can choose Files and conversation; Conversation only keeps the current files. Cancel leaves both alone. Read the file list before confirming: changes made outside Code since the checkpoint may be overwritten for files being restored.

Conversation recovery creates a fork at the earlier point rather than erasing the original session log. Session approvals are cleared when the conversation changes. An old transcript remains evidence, not a promise that the current files still match it.

#Rewind to an earlier message

/rewind lets you choose an earlier message and return to the state before it. Its choices include Files only, Conversation only, or Files and conversation, where a usable checkpoint exists. Unlike /undo, rewind can restore files while retaining the current conversation.

Before message 3, files and conversation are at checkpoint C. After later work, both have advanced. Files-only rewind restores eligible files toward C and keeps the conversation. Conversation-only rewind forks before message 3 and keeps today's files. Both requests both changes. Checkpoint availability and per-file restore results still determine what actually succeeds. The switches only illustrate these choices.

The illustrated README changes from “npm dev” to “npm run dev”. Files-only returns that line to the checkpoint while keeping later messages; conversation-only removes those later messages from the fork while retaining the changed file.

#Read what actually restored

A restore is not an all-or-nothing transaction across every file and the conversation. Some files can restore while others are skipped; Code lists Left as they are with reasons. Files can also restore before a later conversation-fork failure. Inspect both the printed result and the actual files.

If no usable checkpoint was saved before the selected message, Code cannot reconstruct those files from the conversation. It can still offer conversation recovery. Checkpoint settings, exclusions, file limits, and unavailable source material affect coverage. Do not use checkpoint recovery as a substitute for a repository backup or a deliberate commit.

Changes outside the workspace, remote service mutations, generated provider charges, and commands' external effects cannot be undone by returning local files. A process may also still be running; inspect /processes separately.

#Redo before sending another message

After /undo, use /redo to restore what the undo removed, if redo remains available. A new message consumes that redo opportunity. Switching sessions, changing folders, or changing logs from elsewhere can also make the saved redo entry inapplicable; follow the message instead of assuming it is global history.

For file recovery, Code checks the workspace and available restore point again. Read any skipped-file report. Once you are satisfied with the recovered state, continue with a smaller, explicit request and verify the resulting diff.