WorkspacesPersistence
What persists, and what does not
A snapshot is a disk image. Your files, installs and git state come back exactly. Running processes do not: every start is a cold boot.
What survives a pause
- Files and working directories, including uncommitted edits an agent made while you were away.
- Git state: branches, stashes and remotes are where you left them.
- Anything you installed, plus dotfiles and shell history.
- The workspace's event log and its snapshot history.
What does not survive is anything that only existed in memory: running processes, an agent mid-turn, a dev server you started, a shell's unsaved scrollback. When a workspace comes back it boots from its disk, the same way a machine boots after a clean shutdown.
This is a deliberate change, made on 2026-08-20. Earlier copy on this site promised that a paused workspace resumed with its memory intact. It does not, and no version of the product does any more.
When the disk is sealed
- After every agent turn.
- On
reachpad pause, and on an idle pause. - At most every five minutes while the workspace is active, without stopping the guest.
So the worst case for a workspace whose node dies mid-run is five minutes of lost writes, not the whole session. reachpad pause --wait returns only once the save is durable, which is the one to use before you shut a laptop on work you care about.
A workspace pauses itself
A workspace pauses itself after 10 minutes with no terminal input and no supervised agent running in it. A supervised agent that is grinding away with nobody typing keeps its workspace alive for as long as it runs.
A background process you detached from the terminal yourself does not count as activity. A nohup'd script with nobody typing at it will have its workspace sealed and stopped underneath it. Run long work through your agent, or through reachpad run, and keep it in the foreground.
An idle pause is an ordinary pause: the disk is sealed first, and the next run or attach boots the workspace again. It stops the meter, which is the point.
Going back to an earlier state
Every seal leaves a checkpoint you can fork or rewind to. Automatic recovery history is managed rather than kept forever; retained forks and rewinds pin the checkpoints they depend on. See forks and rewind.
This page as raw markdown, for an agent or a prompt: /docs/persistence.md