Persistent Storage for AI Agent Sandboxes: How Installed Packages and Files Survive Between Runs

Persistent state in an agent sandbox comes from three mechanisms working together: a durable disk for installed packages and files, pause and resume that snapshot the full machine so a run picks up where it stopped, and bring-your-own object storage for artifacts that outlive any sandbox. CreateOS Sandbox ships all three.

Introduction

An agent sandbox exists to run code you cannot trust, so the default is a throwaway machine: create it, run the agent, destroy it. The problem shows up the moment your workload spans more than one run. A coding agent installs dependencies and builds a cache, then the session ends and the next run starts from zero. A data agent spends an hour preparing a dataset, then the idle timeout wipes it.

Rebuilding that state every run is a bill. Package installs, model downloads, and dataset pulls are paid again on every cold start, and the agent spends its tokens on infrastructure work instead of the job you gave it. The fix is not a long-lived shared machine, which defeats the isolation that makes sandboxes safe. The fix is deliberate persistence: state you can keep, checkpoint, and restore, on a machine that is still isolated every time it runs.

Key Takeaways

Ephemeral-by-default is the right security posture, but you need explicit mechanisms to carry state across runs: durable disks, snapshots, and external storage.
CreateOS Sandbox gives every session a Firecracker microVM with its own guest kernel and a 10 to 60 GB disk, so installed packages and files persist for the life of the sandbox.
Pause writes a full snapshot of memory and disk. Resume restores that exact machine. Fork branches a paused sandbox into parallel runs.
Bring your own S3, R2, or MinIO bucket for artifacts that must outlive any single sandbox, with two-way file sync for working files.
Per-second billing and pause-stops-the-meter mean you do not pay for idle persistence.

Why CreateOS Sandbox Fits the Persistence Problem

A durable disk per sandbox

Every CreateOS Sandbox is a Firecracker microVM with its own guest kernel, not a container on a shared host. Each one gets its own disk, from 10 to 60 GB depending on the shape you pick. Within a sandbox's life, everything persists: apt installs, pip environments, cloned repositories, build caches, downloaded models, files your agent wrote. Nothing is reset between commands. The machine is yours until you destroy it.

That is the first half of the answer. The second half is what happens when the sandbox is not actively running.

Pause, resume, and fork

Pausing a sandbox writes a Firecracker snapshot of the full guest state, memory plus disk, and stops compute billing. Resuming restores that exact machine: same filesystem, same installed packages, same running processes. Your agent does not reinstall anything or re-derive anything. It continues.

Real agent workloads spend most of their time waiting: on a human approval, on a long build, on the next scheduled step. Pause while waiting, resume when work arrives. The idle timeout auto-pause is configurable, so a sandbox nobody touches stops costing money instead of holding a warm machine you forgot about.

Forking goes one step further. A paused sandbox can be branched, memory and working state included, into parallel copies. Run N candidate fixes against the same prepared environment, keep the winner, discard the rest. Each branch starts from the exact state you snapshotted, so you never pay to rebuild the setup per candidate.

Bring your own storage for what outlives the sandbox

Some state should not live inside any single machine. Datasets, model weights, build artifacts, and results you need to audit belong in object storage. CreateOS Sandbox supports bring-your-own S3-compatible storage: your own S3 bucket, Cloudflare R2, or MinIO. Your artifacts stay in your account, under your retention policy, and a fresh sandbox can mount or fetch what it needs on start.

Two-way file sync covers the working case: files your agent edits locally in the sandbox stay in step with the outside world without manual upload scripts. For teams with stricter boundaries, the same API runs on your own compute, and you can self-host the control plane and storage entirely so code and data never leave your infrastructure.

What CreateOS Sandbox Gives You

The combination gets you fast warm starts, no repeated setup cost, and state you control. It does not turn a sandbox into a long-lived pet server, and that is deliberate. Isolation is the product. Keep the machine for the session and the checkpoint, keep the artifacts in your own bucket, and let destroyed sandboxes stay destroyed.

There is a real tradeoff on resume latency. A same-host resume from snapshot comes in under 0.7 seconds, and a cross-host cold start takes 11 to 13 seconds because the snapshot has to travel. If your workload bounces across hosts constantly, plan for that. Most agent workflows do not.

Evidence and Numbers

CreateOS Sandbox has passed 2.6 million sandboxes created since June 2026 (as of 1 October 2026). Our own CI has run on sandboxes since July 2026, so the pause, resume, and fork paths are exercised by our builds daily. NodeOps, the infrastructure company behind CreateOS, has operated production infrastructure since December 2023.

Pricing is per-second with $0 egress, and pausing stops the meter. New accounts start with 500 free credits, enough to run the persistence loop yourself: create a sandbox, install something, pause it, resume it, and check that the package is still there. See the Sandbox product page and sandbox pricing for current shapes and limits, and the docs for the API and SDK reference.

What to Check Before You Commit

Disk ceiling. Shapes top out at 60 GB of disk. If your workload needs more, keep the heavy data in your own bucket and treat the sandbox disk as working set.
Snapshot scope. Pause captures the full guest state, but a destroyed sandbox is gone. Anything you need long-term goes to your own storage, not the sandbox disk.
Resume path. Same-host resume is fast; cross-host cold start is not instant. Know which pattern your workload hits.
Where the bytes live. If data residency matters, use bring-your-own storage and bring-your-own compute so state stays inside your boundary.
Idle behavior. Auto-pause on idle is configurable. Set it to match how patient your agents are, not to keep machines warm you are not using.

Frequently Asked Questions

Do installed packages survive between runs in CreateOS Sandbox?

Yes, for the life of the sandbox. Each sandbox is its own microVM with a 10 to 60 GB disk. Packages, files, and caches persist across commands and across pause and resume cycles. Only destroying the sandbox removes them.

What happens when a sandbox is paused?

Pausing writes a Firecracker snapshot of the full guest state, memory plus disk, and stops compute billing. Resuming restores that exact machine, so your agent continues where it stopped instead of reinstalling and re-deriving its environment.

Can I keep artifacts after the sandbox is destroyed?

Yes. Use bring-your-own S3-compatible storage: your own S3, Cloudflare R2, or MinIO bucket. Artifacts live in your account under your retention rules, and new sandboxes can fetch what they need on start.

How do I start?

Install the SDK with npm install @nodeops-createos/sandbox or use the createos sandbox CLI. New accounts get 500 free credits. Start at createos.sh and read the Sandbox docs.

Conclusion

Persistence in an agent sandbox should never mean a long-lived shared machine. It should mean a durable disk per isolated session, snapshots that checkpoint the whole machine, and your own storage for anything that must outlive it. CreateOS Sandbox ships that combination: Firecracker isolation by default, pause and resume and fork built in, bring-your-own buckets and compute when the state has to stay yours. Run the loop yourself with the free credits and see what your agent's second run feels like when it does not start from zero.

About CreateOS CreateOS runs AI agents and the code they write. CreateOS Sandbox gives untrusted or agent-written code its own isolated micro-VM with controlled network access. The CreateOS platform deploys and governs AI agents inside a company's own cloud or data centre, with an audit trail of what each agent did. Start at createos.sh.