Skip to main content
File checkpointing tracks file modifications made through the Write, Edit, and NotebookEdit tools during an agent session, allowing you to rewind files to any previous state. Want to try it out? Jump to the interactive example. With checkpointing, you can:
  • Undo unwanted changes by restoring files to a known good state
  • Explore alternatives by restoring to a checkpoint and trying a different approach
  • Recover from errors when the agent makes incorrect modifications
Only changes made through the Write, Edit, and NotebookEdit tools are tracked. Changes made through Bash commands (like echo > file.txt or sed -i) are not captured by the checkpoint system, and neither are edits a subagent applies, except a skill with context: fork that runs in the foreground.

How checkpointing works

When you enable file checkpointing, the SDK creates backups of files before modifying them through the Write, Edit, or NotebookEdit tools. User messages in the response stream include a checkpoint UUID that you can use as a restore point.
File rewinding restores files on disk to a previous state. It does not rewind the conversation itself. The conversation history and context remain intact after calling rewindFiles() (TypeScript) or rewind_files() (Python).
The checkpoint system tracks:
  • Files created during the session
  • Files modified during the session
  • The original content of modified files
When you rewind to a checkpoint, Claude Code deletes the files it created and restores the files it modified to their content at that point. Claude Code skips a tracked path that is a symlink, hard link, or other non-regular file. It also skips a tracked file whose parent directory no longer resolves to its checkpoint-time location, or whose backup it can’t read safely. RewindFilesResult counts every skipped path in its skippedLinks field. Skipping requires Claude Code v2.1.216 or later; before v2.1.216, a rewind wrote and deleted through links at tracked paths.

Implement checkpointing

To use file checkpointing, enable it in your options, capture checkpoint UUIDs from the response stream, then call rewindFiles() (TypeScript) or rewind_files() (Python) when you need to restore. The following example shows the complete flow: enable checkpointing, capture the checkpoint UUID and session ID from the response stream, then resume the session later to rewind files. Each step is explained in detail below. The examples in this section use the prompt “Refactor the authentication module”. Run them in a project that contains an authentication module, or change the prompt to name files that exist in your project, so you can watch files change and see the rewind restore them.
1

Enable checkpointing

Configure your SDK options to enable checkpointing and receive checkpoint UUIDs:
2

Capture checkpoint UUID and session ID

With the replay-user-messages option set (shown above), each user message in the response stream has a UUID that serves as a checkpoint.For most use cases, capture the first user message UUID (message.uuid); rewinding to it restores the tracked files to their original state. To store multiple checkpoints and rewind to intermediate states, see Multiple restore points.Capturing the session ID (message.session_id) is optional; you only need it if you want to rewind later, after the stream completes. If you’re calling rewindFiles() immediately while still processing messages (as the example in Checkpoint before risky operations does), you can skip capturing the session ID.
3

Rewind files

To rewind after the stream completes, resume the session with an empty prompt and call rewind_files() (Python) or rewindFiles() (TypeScript) with your checkpoint UUID. You can also rewind during the stream; see Checkpoint before risky operations for that pattern.
If you capture the session ID and checkpoint ID, you can also rewind from the CLI. This command requires the claude executable, which comes from installing Claude Code and is not installed by the SDK package. The SDK enables checkpointing for you, but when you run claude -p directly you must set the CLAUDE_CODE_ENABLE_SDK_FILE_CHECKPOINTING environment variable:
The --rewind-files flag does not appear in claude --help output, but the CLI accepts it as shown.

Common patterns

These patterns show different ways to capture and use checkpoint UUIDs depending on your use case.

Checkpoint before risky operations

This pattern keeps only the most recent checkpoint UUID, updating it before each agent turn. If something goes wrong during processing, you can immediately rewind to the last safe state and break out of the loop. Before running this example, replace your_revert_condition (Python) or yourRevertCondition (TypeScript) with your own check, such as error detection or a validation failure; the placeholder is not defined in the example.

Multiple restore points

If Claude makes changes across multiple turns, you might want to rewind to a specific point rather than all the way back. For example, if Claude refactors a file in turn one and adds tests in turn two, you might want to keep the refactor but undo the tests. This pattern stores all checkpoint UUIDs in an array with metadata. After the session completes, you can rewind to any previous checkpoint:

Try it out

This complete example creates a small utility file, has the agent add documentation comments, shows you the changes, then asks if you want to rewind. Before you begin, make sure you have the Claude Agent SDK installed.
1

Create a test file

Create a new file called utils.py (Python) or utils.ts (TypeScript) and paste the following code:
2

Run the interactive example

Create a new file called try_checkpointing.py (Python) or try_checkpointing.ts (TypeScript) in the same directory as your utility file, and paste the following code.This script asks Claude to add doc comments to your utility file, then gives you the option to rewind and restore the original.