# 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.

Part of the reachpad docs: https://reachpad.dev/docs. Rendered page: https://reachpad.dev/docs/persistence. Last checked 2026-08-21.

## What survives a pause

- Files and working directories, including uncommitted edits an agent made while you were away, once they have reached the disk. See the note below on flushing.
- 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.

> Note: A write still sitting in the guest's page cache is memory too. A pause seals the block device without asking the guest to flush first, so a file written just before a pause can come back at zero bytes, present but empty. Run `sync` before you pause work you care about. This is a defect rather than a design, it is being fixed, and this note goes when it is.

> Note: 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. It waits for the save, not for the guest to flush, so pair it with `sync` inside the workspace.

## 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.

> Note: 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](https://reachpad.dev/docs/forks).