# What survives when an agent's computer stops? > On Sanbox, a stop keeps the disk: /workspace, installed packages, Docker images and the browser profile. RAM, running processes, connections and exec commands end. - Source: Sanbox knowledge base, by Sanlabs GmbH - URL: https://sanbox.cloud/kb/agent-computers/what-survives-a-stop/ - Type: explainer - Section: Agent computers explained - Language: en - Published: 2026-11-06 - Updated: 2026-11-06 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 ` starts new runs from it. - **Delete** permanently removes the saved disk. ```bash sanbox runs stop --wait --json sanbox runs resume --wait --json sanbox runs fork --request-key --wait --json sanbox snapshots create --run --name --wait sanbox runs delete --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 --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 --detach --json -- ` and follow them with `sanbox commands logs --follow`. - **Connections:** old tokens stop working, so create new ones after each resume with `sanbox opencode connect --expires 1h --json` or `sanbox ports connect --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. ## Related - [Persistent vs ephemeral sandboxes for AI agents: which do I need?](https://sanbox.cloud/kb/agent-computers/persistent-vs-ephemeral-sandboxes/) - [How do I try three approaches from the same starting point?](https://sanbox.cloud/kb/parallel-work/fork-a-computer-to-try-several-approaches/) - [How do I keep an agent's browser logged in between sessions?](https://sanbox.cloud/kb/browser/keep-an-agents-browser-logged-in/) - [How do I run Docker Compose inside an AI agent's sandbox?](https://sanbox.cloud/kb/parallel-work/docker-compose-inside-an-agent-computer/) ## Sources - [E2B: Sandbox persistence](https://docs.e2b.dev/sandbox/persistence) (checked 2026-11-06) - [Daytona: Sandboxes](https://www.daytona.io/docs/en/sandboxes/), lifecycle, auto-stop and auto-archive (checked 2026-11-06) ## Next step Talk to us at sales@sanlabs.ai. Sanlabs' forward-deployed engineers build agent use cases with your team, with experience in aviation, pharmaceuticals, supply chain and logistics, and internal admin workflows. How we work: https://sanbox.cloud/kb/teams/forward-deployed-engineering.md Existing customers can use Sanbox from a coding agent: install the CLI with `npm install -g @sanlabs/sanbox-cli@latest`, sign in with `sanbox login`, then run `sanbox skill` for the full agent guide.