Undoing what an agent did: checkpoints, version control and their limits
Undoing an AI agent's actions requires restore points. What is easy to revert, what is not, and how to design undo so people trust the system.
Why is undo part of the design?
An agent that acts fast can also be wrong fast. If the person has no clear way back, they stop delegating tasks to it. Undo is what makes autonomy tolerable: you know that a mistake has a way out. The permissions that define what the agent may touch, covered in permissions UX for agents, are the other half of that trust.
There is a basic difference worth being clear about from the start. Reverting a file change means recovering a state. Reverting an effect in the world, such as a message that has already reached a customer, is not possible. An honest design does not promise to undo what cannot be undone.
How do restore points work?
Claude Code, for example, records a checkpoint before each message that starts a turn. According to its documentation, it keeps file snapshots for the 100 most recent checkpoints in a session, and lets you restore the code, the conversation or both from a rewind menu. It also offers to summarize the conversation from a point, to free up context space.
The same documentation lists limits worth knowing:
- Changes made by terminal commands are not tracked. If the agent runs
rm,mvorcp, rewind cannot undo them. Only edits made by the editing tools are tracked. - Edits by subagents and other sessions are not guaranteed. Do not count on rewind for them; keep git as a backup.
- External changes are not recorded. What the person changes by hand, outside the session, normally does not enter the checkpoint.
- Checkpoints are not forever. Only the 100 most recent in the session are kept, and with old sessions a rewind can fail because the files no longer exist.
The lesson from this list is that undo depends on which tool made the change. A design that promises undo in general misleads people.
What role does version control play?
Version control is the strongest safety net for code changes. Anthropic, describing how an agent works across many sessions, recommends descriptive commits: they allow a return to a working state and the reversal of a bad change without depending on the session.
For a designer working with agents, the lesson is practical: if the product saves changes to a repository, each important turn should end in a commit with a message saying what the agent did. Then undo is a git revert, not a guess.
What can be undone and what cannot?
| Type of action | Can it be undone? | How |
|---|---|---|
| File edit made by the editing tool | Yes | Checkpoint or version control |
| Terminal command that modifies files | Hard | Only with git or earlier copies |
| Record created in your system | Depends | Delete it, if the system allows |
| Email, message or notification sent | No | Only compensated with another message |
| Payment or charge executed | No | Requires a refund process |
The last rows are the ones most often forgotten. For actions that cannot be undone, protection is up front: approve them before they happen, rather than reverting them afterwards. That is the territory of action approval, and of showing the effect beforehand with previewing changes.
How do you design undo?
- Show what will be reverted before confirming. “Restore the code to 2:32 pm” is clear. A bare “Undo” is not.
- Separate code and conversation. Sometimes the person wants to go back to the code but keep the conversation, or the reverse. Offering both prevents losing something by accident.
- Mark what cannot be reverted. If an action had an external effect, say so with the same visual weight as the undo button.
- Keep the record. Even when something is reverted, what the agent did and when should stay visible. That serves auditing and understanding the mistake.
Example
Illustrative example: an agent refactors the styles of an application and, by mistake, also changes the theme configuration file. The person notices three turns later.
The team has checkpoints per turn and commits at the end of each task. The person opens the restore menu, chooses the point before the refactor and restores only the code. The theme file comes back. But the agent also ran a terminal command that generated temporary files in another folder: the checkpoint did not track them, and the person had to delete them with git. The team added to its guide that terminal commands are reviewed at the end of each task.
When should you NOT promise undo?
When the action has an effect outside the system, when the system does not record its changes, or when restoring could overwrite other people’s work. In those cases the design must build trust another way: prior approval, unsent drafts or a preview of the effect.
Common mistakes
- Promising a general “undo” when it only covers files edited by one tool.
- Showing the button without saying which state will come back.
- Not separating what is revertible from what is external.
- Relying only on the session and not on a commit history.
- Forgetting that checkpoints are limited and rewind can fail.