Guides / Save and undo

Save and undo

An autonomous assistant will eventually do something destructive. The usual answers are to approve every action, which defeats the point, or to rebuild the environment, which throws away everything that made it useful. kosa8 offers a third.

Why this works at all

kosa8 saves memory and running processes, not just files. So a restored machine is not a fresh one that has to be set up again — it is the same machine, mid-task, as it was seconds earlier. A database still holding its connections is still holding them.

Take a checkpoint before the risky step

$ kosa8 checkpoint web --label "before migration"
checkpoint web-ckpt-1 (before migration) saved in 2281ms
  rewind with `kosa8 rewind web`

The label is the useful half of the record. "before migration" tells whoever reviews this later why you thought the next step was worth guarding.

Let it go wrong

Anything: a migration that half-applies, a mass delete, a dependency upgrade that breaks the build. It does not matter, because you are about to undo it.

Rewind

$ kosa8 rewind web
Rewind web to web-ckpt-1 — before migration?
Everything since 2m ago will be lost. [y/N] y
web is back at web-ckpt-1 (1065ms)
  processes resumed from 2m ago

About a second, and the sandbox keeps its name — so scripts, agent configuration and your shell history all still point at the right thing. That is the difference between an undo button and "here is a new sandbox, please rewire everything".

Several checkpoints

$ kosa8 checkpoint ls web
CHECKPOINT     WHEN       TAKEN   WHY
 web-ckpt-1    12m ago    you     before migration
 web-ckpt-2    4m ago     you     after the schema change
*web-ckpt-3    just now   you     before the risky bit

* is where `kosa8 rewind web` goes

Rewind to an earlier one by label or id:

$ kosa8 rewind web --to "before migration"
web is back at web-ckpt-1 (941ms)
  dropped 2 later checkpoint(s)

Why the later ones are dropped

They describe a future that no longer happened. Keeping them would leave restore points that claim to hold state this machine never reached.

Things worth knowing

Ten per sandbox. Each checkpoint costs a disk clone, so an assistant checkpointing on every step would otherwise fill the disk. The oldest is dropped when you hit the limit.
Rewinding destroys current state. It cannot itself be undone, so take a checkpoint first if you might want the current state back.
Use -y to skip the prompt in scripts, and --json for machine-readable output.

From an AI assistant

The same thing over MCP, so an assistant can guard its own work without you typing anything:

sandbox_checkpoint       save a restore point, with a label saying why
sandbox_checkpoint_list  what restore points exist
sandbox_rewind           go back to one

Next

Try several ideas at once — the other thing saving a running machine makes possible.