Which AI Sandbox Providers Retain Packages and Files Between Sessions

Sandbox providers describe their products as "persistent," and that single word is hiding three different engineering decisions that most platforms only make two of, at best. A builder evaluating infrastructure for a stateful agent needs to pull the word apart into its component parts: does the filesystem come back with files and installed packages intact, does the running process and its in-memory state come back, and how long does any of that last before the platform wipes it clean? These three properties, filesystem survival, process and memory survival, and expiry policy, do not travel together as a package deal. A platform can nail one and skip the other two, and the marketing copy will still say "persistent" either way.

The gaps between these three properties are what separate an architecture that actually works for long-horizon agent work from one that only looks like it does in a demo. An agent that runs for ten minutes and exits rarely tests any of this, since nothing has to survive a gap. But an agent that works across days, pauses between steps, or waits for a human review cycle, depends entirely on what's still there when it wakes up. Snapshot-based persistence and live-volume persistence sound similar on a feature page, but they behave very differently once you use them. A snapshot copies state out to storage and rebuilds it on resume, which adds latency and introduces a recovery boundary where things can go wrong. A live volume just stays mounted, so there's nothing to copy and nothing to restore. That difference shapes how fast a sandbox wakes up and what happens when the sandbox stops unexpectedly.

Why does any of this matter beyond a technical curiosity? Consider three agents doing different jobs. A coding agent needs its cloned repository and whatever packages it installed to still be there on the next run. A computer-use agent needs all of that plus an authenticated browser session, cookies and tokens that can't simply be regenerated. A long-horizon research agent needs its conversation history and whatever data it already crawled, because re-crawling is slow and expensive. Each of these fails differently when the platform delivers persistence on paper but not on the specific property the agent actually depends on.

How each provider handles filesystem, process state, and expiry

No two platforms claiming persistence combine filesystem survival, process survival, and TTL policy the same way, because each one made its own real architectural choices, not just small configuration quirks.

Daytona was built specifically for running AI-generated code in isolated runtimes, and its approach treats statefulness as the default rather than an add-on: sandboxes are stateful by design, so an agent can resume long-running work exactly where it stopped. Filesystem state persists by design, process and memory state carry across sessions, and sandboxes can run indefinitely with no fixed TTL counting down toward teardown. Startup lands under 90 milliseconds, and the platform runs container-native, so existing container workflows don't need rewriting to use it. Daytona also supports customer-managed compute (BYOC), keeping data inside a customer's own cloud even though the control plane itself stays vendor-hosted, and the project is open source rather than a closed black box, with SOC 2, HIPAA, and GDPR compliance built into its posture.

Fly.io Sprites keep the filesystem alive through NVMe-backed sync, meaning files survive, but process and memory state do not come back after a pause. There's no fixed session limit stated for how long that filesystem state can persist. Warm wakes are 100 to 500 milliseconds and cold starts are one to two seconds, which is fast, though the agent still has to restart whatever was running.

Blaxel takes a different approach: sandboxes sit in standby indefinitely at zero compute cost and resume in under 25 milliseconds with filesystem, memory, and running processes all intact. That's a more complete form of persistence because it includes process state as well as files. Sandbox state survives standby, but deleting the sandbox erases it, since the durability guarantee is tied to the sandbox's own existence. Blaxel runs microVM isolation so each workload gets its own kernel, and it offers Agent Drive, a distributed filesystem currently in private preview that mounts across multiple sandboxes with concurrent read-write access, plus Volumes for durable block storage. Compliance coverage includes SOC 2 Type II, ISO 27001, and HIPAA support.

Vercel Sandbox runs SDK-managed microVMs and takes snapshots that include both files and installed packages. Filesystem and directory snapshots are retained 30 days by default, though that window can be configured to any duration, including indefinitely. Resuming a named sandbox starts an entirely new VM from the filesystem snapshot, so live processes and open sockets do not come back, and any running commands or connections have to be restarted after every resume. Vercel Drives, now in public beta across Hobby, Pro, and Enterprise tiers, exist for cases where data needs to outlive a single sandbox or get reused across separate runs.

Cloudflare's Sandbox stops the container after a default 10-minute idle timeout, and when that happens, everything goes: files are deleted, processes terminate, and interpreter contexts clear out. Recovering anything after that point means restoring from a backup explicitly, since nothing survives automatically. Persistence is possible, but it requires mounting S3-compatible object storage, through R2, S3, or GCS, as an external layer that lives outside the sandbox's own lifecycle.

Perplexity's Sandbox API keeps sessions stateful through a persistent filesystem mounted via FUSE. Files created in one step of a workflow are available in later steps, so long-running workflows can pause and resume hours later with full state intact, pointing to a design built around multi-step agent tasks.

Windmill pairs sandboxing with volumes for AI coding agent workflows, so agents can store session IDs, conversation history, or memory files in an attached volume and pick up from that stored state on the next run. The filesystem persists through that attached volume, with process isolation handling the execution side.

AWS AgentCore takes the opposite philosophy from most of the field: it deliberately destroys the microVM once a session ends, and sessions are bounded in length, with an 8-hour maximum before full teardown. Nothing about the filesystem or process state is designed to survive past that window, a deliberate design choice.

Google's GKE Agent Sandbox preserves disk state across a pause, releasing compute resources while keeping all in-container filesystem state intact at the moment of pause. That state is still bound by a hard limit, 14 days, after which the sandbox's state is no longer guaranteed to exist.

Why snapshot-based persistence breaks down under agent workloads that accumulate state over time

Snapshot-based persistence is the approach most of the field has converged on, and accumulating state over days or weeks rather than minutes exposes a structural problem in that approach. The snapshot model works by copying state out to storage when a sandbox pauses and rebuilding that state when it resumes. The TTL attached to that snapshot pipeline functions as an architectural constraint, not a billing detail buried in a pricing page.

Consider what happens when the snapshot expires before the agent resumes. Vercel's filesystem snapshots default to a 30-day retention window, with memory-state snapshots retained for 7 days. Google's GKE Agent Sandbox enforces a 14-day hard limit on sandbox state. AWS AgentCore avoids snapshotting altogether by tearing the microVM down completely at session end. In each case, once the clock runs out, whatever context the agent built up over its working life is gone, with no path to recover it. For an agent that reconstructs its environment from scratch on every invocation, re-cloning a repository, reinstalling packages, re-crawling a dataset it already crawled once, the cost compounds every time a session boundary gets crossed. That cost appears twice: once in wall-clock latency while the agent rebuilds what it already had, and once in token spend re-processing information it already processed.

The practical failure mode is straightforward to describe: engineering hours and compute budget go toward reconstructing context the agent had already produced, an inefficiency that undercuts the entire premise of running a long-horizon agent. Platforms built around live-volume or perpetual-standby models sidestep this problem, because they never copy anything out to begin with. Northflank's attached volumes, Blaxel's indefinite standby, Daytona's stateful-by-design runtime, and Fly.io's NVMe-backed filesystem sync all share this trait: state simply stays where it is rather than getting shuttled through a snapshot-and-restore pipeline with a TTL attached to it.

One might object that snapshot TTLs are usually configurable, and extendable at the enterprise tier, so the risk described above is really just a configuration problem waiting for the right settings. That's a fair point as far as it goes, but it treats a structural question as though it were a dial someone forgot to turn. If an agent's continuity depends on a TTL that hasn't expired yet, it is running against an undeclared deadline, and tracking that deadline across a fleet of long-running agents, each with its own snapshot clock, becomes its own operational burden and its own source of production risk. Whether the TTL can be extended matters less than whether anyone is reliably extending it before it runs out, across every agent, every time.

Computer-use agents sharpen this problem considerably. A browser session authenticated with a password and a two-factor code isn't something that can be rebuilt cheaply on demand. Reconstructing it requires either a human stepping in or a fresh authentication flow, and an autonomous agent running unattended at 2 AM has access to neither. For that class of agent, the gap between a platform that preserves process and memory state and one that only preserves files isn't a convenience question. The agent can keep working only until the snapshot clock runs out.

Isolation Model, Persistence, and the Session Boundary

Persistence introduces a security requirement that ephemeral sandboxes never have to deal with: a sandbox holding state across sessions has to serve one tenant exclusively for as long as that state exists, not just for the length of one task.

Ephemeral sandboxes get their isolation guarantee essentially for free, through teardown. Once a session ends, the environment disappears, and there's no way for it to bleed into whatever tenant spins up next. A persistent sandbox doesn't get that free pass. Its isolation boundary has to hold across an open-ended lifecycle, which raises the stakes on what kind of isolation is running underneath it. Shared-kernel containers leave escape paths, but a short-lived sandbox might never encounter them, simply because its window of exposure closes quickly. A persistent container keeps that window open far longer, so platforms built for persistent workloads tend to reach for microVM isolation, using Firecracker or Kata Containers, as the stronger isolation option. A microVM runs its own kernel per sandbox, so it closes off the escape paths that a shared kernel carries by default.

The session boundary itself is where credential exposure risk concentrates most heavily. A persistent sandbox may be holding API keys, access tokens, or an authenticated session across multiple resumes, not just within a single run. Losing isolation at the moment of resume carries more weight than losing it at first boot, because by the time a sandbox resumes, it may already be holding secrets that a brand-new sandbox never would have accumulated yet.

Architecture that separates the data plane from the control plane changes this calculus. Platforms supporting BYOC, bring-your-own-compute, let sandboxes run inside a customer's own VPC. Northflank offers this, and Daytona offers it experimentally through invite-only customer-managed compute. Even when the control plane stays shared across the provider's customer base, the workload data itself stays within the customer's own infrastructure under this model, giving a meaningfully different trust boundary than a setup where both planes sit on the provider's side. That distinction matters more once compliance obligations enter the picture, because a sandbox holding regulated data across sessions is a very different liability depending on whose infrastructure that data actually touches.

Compliance posture across providers for teams with HIPAA, SOC 2, or GDPR obligations

If you run persistent execution through third-party infrastructure, you bring a third-party data processor into your compliance chain, and providers have not all covered that obligation to the same degree.

Each regulatory framework triggers its own specific requirement. GDPR requires a Data Processing Agreement between the company and whatever processor is handling the data. HIPAA requires a Business Associate Agreement before any protected health information can touch the platform. SOC 2 Type 2 functions as the baseline attestation that auditors look for regardless of industry. A persistent sandbox holding customer-derived data across sessions falls squarely within scope for all three, because the whole point of persistence is that data sticks around long enough to matter for exactly the kind of audit these frameworks are built around.

Coverage varies by provider. Daytona's compliance posture includes SOC 2, HIPAA, and GDPR built in in, which matters directly for teams in regulated industries evaluating where to run agent workloads that touch sensitive data. Blaxel supports SOC 2 Type II, ISO 27001, and HIPAA. Fly.io offers GDPR compliance through a pre-signed Data Processing Agreement, and customers who need one can request it. Each of these represents a different combination of attestations and agreements, and a team's own regulatory obligations should drive which combination actually fits, rather than treating compliance as a single checkbox that every platform either has or doesn't.

What ties this back to the earlier sections is that compliance and architecture aren't separate concerns to evaluate independently. A platform with strong HIPAA and SOC 2 coverage but a snapshot pipeline with a short TTL is handling regulated data under the same reconstruction-cost and exposure-risk problems described above, just with an audit trail attached. Evaluating a sandbox for stateful, regulated agent work means asking about filesystem survival, process survival, TTL policy, isolation model, and compliance posture together, because a gap in any one of those five areas changes what the sandbox can actually be trusted to hold.