What survives when an agent's computer stops?

On a Sanbox Computer, everything on the disk survives a stop: files in /workspace, installed packages and other system changes, Docker images and volumes, the browser profile and the agent's history. Everything in memory does not: RAM, running processes, open connections, exec commands and connection tokens. Resume boots the Computer fresh with the saved disk, so plan for services to start again. With other providers, check the same two things: what stays on disk, and whether memory is kept.

What do stop, resume, fork, snapshot and delete do?

Stop ends compute and saves the disk. Docker containers get up to 15 seconds to exit before they are killed. A stopped Computer isn't deleted automatically while your account is active.
Resume boots the Computer's pinned runtime fresh with that saved disk.
Fork copies a stopped Computer into a new, independent run that boots fresh. The original task is not replayed.
Snapshot saves a named copy of a stopped Computer, and sanbox run --snapshot <name> starts new runs from it.
Delete permanently removes the saved disk.

sanbox runs stop <run-id> --wait --json
sanbox runs resume <run-id> --wait --json
sanbox runs fork <stopped-run-id> --request-key <uuid> --wait --json
sanbox snapshots create --run <stopped-run-id> --name <name> --wait
sanbox runs delete <run-id> --yes --json

What is kept, item by item?

What	Stop, then resume	Fork	New run from a snapshot	Delete
Files in `/workspace`	Kept	Copied	Copied	Removed
Installed packages and other system changes	Kept	Copied	Copied	Removed
Docker images, build caches and volumes	Kept	Copied	Copied	Removed
Docker containers	Kept; restart only with a restart policy	Same as resume	Same as resume	Removed
Browser profile: cookies, local storage, signed-in sessions	Kept	Copied	Copied	Removed
Agent history and memory (OpenCode, Hermes)	Kept	Copied	Copied	Removed
RAM and in-memory state	Lost	Not copied	Not copied	Gone
Running processes, terminal sessions, dev servers	Ended; the built-in agent restarts, your processes don't	Not copied	Not copied	Gone
Open network connections	Closed	Not copied	Not copied	Gone
`exec` commands and their output	Forgotten	Not copied	Not copied	Gone
SDK and port connection tokens, file shares, SSH sessions	End; create new ones	Don't carry over	Don't carry over	End
Docker registry logins	Lost; they live in memory	Not copied	Not saved	Gone

A few details behind the table:

Credentials in files travel with the files. Forks copy files as they are, including any tokens written into them, and snapshots keep the disk as it was. Secret Proxy credentials aren't stored on the Computer's disk; Sanbox applies the template's grants each time a Computer boots.
Snapshots and forks outlive their source. Deleting a Computer doesn't delete snapshots taken from it, and once a fork has finished copying, deleting either run doesn't affect the other.
Disk size travels too. A template's disk is 1 to 8 GB. Forks and runs from a snapshot keep the size they were copied with.
Template changes don't reach old runs. Existing Computers, forks and snapshot runs keep the settings they started with.
Fork has limits. It works on stopped Computers with a writable disk, not on one-shot task runs. Computers with email, Telegram or Supabase bindings can't be forked.
Check the save. sanbox runs get <run-id> --json shows workspace.saved_at, the time the disk was last saved.

How do I get my services back after a resume?

Docker containers: give them a restart policy, such as restart: unless-stopped in your Compose file.
Terminal sessions: the console's terminal, and zellij if you start it over SSH, keep a session alive when your connection drops, but not across a stop. Start long jobs again after a resume.
Long commands: have them write progress to /workspace so they can pick up where they stopped. Start them with sanbox exec <run-id> --detach --json -- <command> and follow them with sanbox commands logs <run-id> <command-id> --follow.
Connections: old tokens stop working, so create new ones after each resume with sanbox opencode connect <run-id> --expires 1h --json or sanbox ports connect <run-id> --port <port> --expires 1h --json.

What should I check with other providers?

Ask these before you rely on any agent machine:

Does a stop keep the whole disk, or only one mounted folder?
Are system packages you installed kept, or only files under one path?
Is memory saved, so processes carry on mid-step, or does the machine boot fresh?
Do idle machines stop on their own, and after how long?
How long are stopped machines kept? Are they archived or deleted automatically?
What happens to browser profiles and their cookies?
Do snapshots or forks copy credentials stored on disk?

Two providers' current documentation, as examples:

E2B saves both the filesystem and memory when you pause a sandbox, including running processes, and keeps a paused sandbox until you kill it.
Daytona keeps the filesystem and clears memory when a sandbox stops. By default a sandbox stops after 15 minutes without qualifying activity, even with processes still running, and a stopped container sandbox is archived to object storage after 7 days.

When Sanbox is not the right fit

You need processes to carry on exactly where they were. Sanbox doesn't save memory; resume is a fresh boot from the saved disk. A provider that snapshots memory, such as E2B's pause, fits better.
You want idle machines to stop themselves. OpenCode and Hermes Computers run until you stop them, so your app or a script has to do that.
You need more than 8 GB of disk per Computer today. Larger disks are on request.

Sources

E2B: Sandbox persistence (checked 2026-11-06)
Daytona: Sandboxes, lifecycle, auto-stop and auto-archive (checked 2026-11-06)