What your coding agent's checkpoints can't bring back
You ask an agent to clean up some old code. It edits a file, runs rm -rf src/legacy, and the tests go red. No problem, you think: there's a rewind button.
Whether that button brings src/legacy back depends on which agent you're using, and on details most of us never read. I went through the source code and docs of a dozen agents to find out. This is what I found.
Two ways to take a checkpoint
Every agent's undo falls into one of two families.
Track your own edits. The agent remembers the files its own edit tools touched, and puts those back. Claude Code's /rewind, Cursor, VS Code Copilot, Gemini CLI's /rewind and Aider work this way. It's cheap and fast, and it has one big hole: anything a shell command changed isn't tracked. rm -rf, git checkout ., a migration, a build script, sed -i: none of it comes back.
Snapshot the whole tree. The agent takes a git snapshot of the working tree, before or after each step. Cline, opencode and Kilo, Zed, and Gemini CLI's /restore work this way. These can undo what a shell command did, as long as the files weren't ignored by .gitignore.
Neither family backs up ignored files. Your .env is ignored, so no agent will bring it back. And most whole-tree snapshots need the project to be a git repository in the first place.
| Agent | How | Undoes shell changes | Without a git repo |
|---|---|---|---|
Claude Code /rewind | tracks its edit tools | no (documented) | yes |
| Cursor | tracks its edit tools, per prompt | no | yes |
| Codex CLI | no file undo (/undo was removed in 2026) | no | — |
| Cline | commits the whole tree after each tool call | yes | yes |
| opencode, Kilo | write-tree before and after each step | yes | no |
Gemini CLI /restore | whole tree before edit tools (off by default) | indirectly | yes |
Aider /undo | commits to your git | no | no |
The full table, with Zed, VS Code Copilot, Copilot CLI and where each one keeps its snapshots, is in the comparison, with a source for every row.
Five ways it has already gone wrong
These are all real reports from the agents' own issue trackers.
A restore that destroys. Copilot CLI's checkpoint restore ran git clean -fd on the repository. It deleted every untracked file, including over a gigabyte of evaluation output that a script had produced and the agent had only read (github/copilot-cli#1675). Cline had a variant of the same problem when .gitignore itself had uncommitted changes (cline/cline#14367). The undo was the thing that lost the data.
A rewind that silently does nothing. In auto mode, Claude Code is told to make file changes through Bash. Bash edits aren't tracked, so /rewind reports success and leaves every change on disk. The reporter only noticed later, after the agent had carried on building on code they thought they'd rejected (anthropics/claude-code#87575).
A .git that fills up. Codex Desktop stores checkpoint snapshots as refs inside your repository. On a project with large files, one user found 102 GB of orphaned objects in .git/objects (openai/codex#29388).
Snapshots collected as garbage. opencode prunes its snapshot store with git gc --prune=7.days, which can delete objects that older, still-resumable sessions need for diffs and undo. It has already broken review diffs (anomalyco/opencode#36093).
A checkpoint that stalls every turn. Snapshotting a whole large repository isn't free: one report describes about 90 seconds of blocking delay on every turn (cline/cline#13131).
None of this means these agents are careless. Checkpointing is genuinely hard: you're racing an agent that can run any command, in a folder full of things you didn't ask to be tracked.
What helps, whatever you use
- Commit before you hand over. A commit, or
git stash, before a long agent task is the cheapest insurance there is. - One worktree per agent. If two agents, or you and an agent, work in the same folder, an undo in one rolls back the other.
- Check after a rewind. Run
git status. A rewind that reports success isn't proof. - Back up what's ignored.
.env, local databases, data files: no agent snapshots them. - Don't start agents in your home folder. A whole-tree snapshot of it is either skipped or enormous.
- Know your agent's family. If its undo only tracks its own edits, assume anything done through the shell is permanent.
- Use a sandbox for code you don't trust. Undo puts files back. It doesn't undo network requests, deployments or database writes.
Why I built Zerostel
I use more than one agent, and each one gave me a different answer to "what changed, and can I get it back?" So I built Zerostel: a flight recorder and time machine that sits outside the agents.
src/legacy with rm -rf and breaks the tests; npx zerostel undo brings it back. 25 seconds, no sound.It hooks into Claude Code, Codex, Cursor, Copilot CLI, Gemini CLI, Antigravity and opencode, and takes a snapshot before and after every tool call that can change files, shell commands included, into a separate shadow repository. It never touches your .git, backs up small ignored files like .env, and works without a git repo. Before a rewind it snapshots the current state, so every rewind can itself be undone, and it only removes files it holds a copy of. It also keeps a timeline you can read, guardrails that block or ask before a tool runs, and a log that shows if it was edited.
It has limits too, and they're written down: it isn't a sandbox, it only restores states it captured, and it can't rewind the agent's conversation.
Try it in thirty seconds
No agent and no real project needed: it makes a throwaway one and plays one agent turn into it.
npx zerostel demo
Agents change quickly. If something here is out of date, open an issue and I'll fix it.