Undo with checkpoints

You are not asked to approve every file the agent writes. That would make it useless. Instead, Snaga takes a snapshot of your working tree before each destructive action, so anything it did can be put back.

Undo the last thing the agent did

> /rewind

This pops the most recent checkpoint and restores your working tree to the state it was in immediately before that action.

How the snapshots work

Before running any tool that declares itself destructive, the agent stores the working tree as a git stash entry — tracked changes and untracked files alike, so a file the agent has just created is in the snapshot and /rewind removes it again. Up to 20 checkpoints are kept per session; older ones fall off the end.

Your staging area is left exactly as it was. Folding untracked files in needs git add -A, which would otherwise overwrite a carefully staged index on every destructive tool call, so the index is snapshotted first and restored afterwards.

One exception. If the index cannot be snapshotted — during a merge or rebase with unresolved conflicts, git write-tree fails — the untracked fold is skipped and the checkpoint covers tracked changes only. The alternative would be running git add -A with no way to put the index back, destroying the conflict state you are in the middle of resolving. So mid-conflict, a new file the agent creates is not in the snapshot and /rewind will not remove it.

Destructiveness is a property each tool declares, resolved at the moment of the call — not a hardcoded list of tool names. A WASM tool counts as destructive when it holds any capability that can mutate something: file_write, shell_exec, http_post, process, the hardware buses, mqtt.

Because it is git stash, this needs the working directory to be a git repository. In a directory that is not one, there is nothing to snapshot into and no undo to offer.

What happens to work you did after the checkpoint

Restoring a checkpoint overwrites tracked files, which would destroy edits made after the snapshot — including yours.

So /rewind snapshots the current state first, into a separate snaga-rewind-undo stash entry under a different prefix, so the next /rewind will not pick it up. The rewind is itself reversible. If you rewind and realise you have thrown away something you wanted, that stash entry holds it.

What checkpoints do not cover

A checkpoint is a snapshot of your working tree. It does not reach anything that left the machine or touched the world:

• a command that pushed a commit, sent a request, or deleted a remote resource;
• files outside the repository;
• untracked state your tools keep elsewhere.

For the wider case there is /rollback, which reverses the recorded side-effects of a session: file writes, SPEC installs and WASM tool creations are undone automatically, while shell runs and remote HTTP mutations are surfaced for you to deal with by hand — because nothing can honestly claim to un-send a request.

The rule worth internalising: checkpoints make edits cheap to undo; they do not make actions cheap to undo. That difference is why dangerous commands still ask before they run.