Docs › Agent
Checkpoints and undo
Every way back: undoing one run, and restoring the whole workspace to an earlier point.
There are two ways back, at different granularities.
Undoing a run
Every run's summary card has an undo, which puts each file the run touched back to what it was before the run started. It is the right tool when a run did one thing and that thing was wrong.
Checkpoints
A checkpoint is a snapshot of the whole workspace, taken before each turn. Once a run spans dozens of edits and a few shell commands, per-run undo is the wrong granularity: you want to go back to a specific moment, not to the beginning.
Checkpoints live in a separate repository outside your project, driven with their own git directory. This is the important part: committing into your repository would move your HEAD, rewrite your index and drop your staged changes. An editor feature that silently unstages a careful git add -p session is worse than no feature. Nothing about checkpoints touches your .git/.
Because they are outside your repository, checkpoints survive a branch switch and never appear in your diffs, and your own commits, branches and stashes are untouched by them.
What a restore does not bring back
A restore puts tracked files back. Things the agent created that were never snapshotted (build output, files matching your ignore rules) are left alone, so restoring does not wipe a node_modules or a .env you would have to rebuild.
All documentation
Get started
Agent
- Agent overview
- Approvals and permissions
- Plan mode
- What the agent can do
- Running commands
- Browser tools
- Checkpoints and undo
- Infrastructure as code
- Running several agents at once