AI Agent Sandbox Persistence: What Survives Each Lifecycle?

An AI agent sandbox can be called persistent while preserving only a name, only a filesystem, or an entire running machine. The difference appears when the environment sleeps, pauses, stops, crashes, or gets deleted. A reliable architecture therefore starts with a state contract: which layer survives each transition, how it returns, and which effects have already escaped the sandbox.

This guide builds that contract. It compares current first-party documentation for Azure Container Apps, Cloudflare, Runloop, Vercel, E2B, Blaxel, and Docker Sandboxes, verified on July 23, 2026. Product details will evolve. The five-layer model and the acceptance test are designed to remain useful when they do.

Core takeaway: treat sandbox-local state as a cache until a documented and tested lifecycle contract proves otherwise. Put durable work in storage whose lifecycle you control, and make external writes idempotent because deleting a sandbox does not reverse them.

Lifecycle Verbs Need a Contract

Provider APIs use familiar words for different transitions:

• Sleep or standby usually means platform-managed scale-to-zero after inactivity. Cloudflare starts a clean container after sleep. Blaxel restores memory, processes, and files after standby.
• Pause or suspend can mean a full machine checkpoint or a disk-only checkpoint. E2B preserves memory and processes. Runloop preserves disk and requires processes to restart.
• Stop or shutdown can preserve a filesystem, terminate a resource, or trigger a snapshot. Vercel snapshots a persistent sandbox on stop. Docker keeps its VM-owned filesystem across stop and restart.
• Delete, destroy, kill, or remove is normally terminal for provider-owned compute state. Independent volumes, host-mounted files, and external API writes can remain.

These verbs describe control-plane actions. They do not define state by themselves. The useful question is concrete: after this action, can the next execution read the same file, find the same process, use the same connection, mount the same data, and determine whether an earlier external write committed?

A stable sandbox ID is also weak evidence. Cloudflare routes the same ID to the same Durable Object, while the underlying container can restart with a clean filesystem. Identity helps routing. Durability requires a separate guarantee.

A Five-Layer State Model

The state of an agent environment fits into five layers. Each layer has a different owner and failure mode.

1. Process and memory state

This layer includes running processes, RAM, loaded variables, shell sessions, open file descriptors, and in-memory databases. A full memory checkpoint may restore these objects. Disk-only suspend starts fresh processes from preserved files.

Even a full memory checkpoint has a boundary. A restored file descriptor says the local kernel remembers a socket. The database, queue, or HTTP server on the other end may have closed it. Applications still need reconnect and retry logic.

2. Local mutable filesystem

This is the sandbox-owned writable layer: checked-out code, installed packages, build caches, /tmp, home directories, and configuration written during execution.

Local disk is often fast and convenient. Its lifecycle may be tied to a container, a VM, a sandbox identity, or a snapshot retention policy. That ambiguity makes it a good cache and a risky system of record.

3. Checkpoints and reusable environments

Snapshots, saved templates, disk images, and blueprints all accelerate recovery, but they express different contracts:

• A pause/resume checkpoint usually continues one sandbox identity.
• A snapshot commonly creates a point-in-time artifact that can fork one or more new sandboxes.
• A template, image, or blueprint defines a reusable starting environment. It may be declarative, or it may capture a configured filesystem.

The security consequence matters as much as speed. A snapshot can contain runtime files and memory. A saved template can contain credentials accidentally written to disk. Recovery artifacts need retention, access control, and secret-handling policies of their own.

4. External durable storage

Volumes, drives, object-storage mounts, and host bind mounts have lifecycles outside the sandbox. They are the natural place for work that must outlive compute, although their consistency and sharing semantics still vary.

This layer also changes the meaning of deletion. Removing a Docker Sandbox leaves its directly mounted host workspace intact. Deleting a Blaxel sandbox leaves an attached volume available for a future sandbox. Destroying a Cloudflare container does not delete objects already written to R2.

5. External systems and side effects

An agent may push a Git commit, update a database, enqueue a job, send a message, create a cloud resource, or initiate a payment. Those effects crossed the sandbox boundary. Sandbox rollback and deletion do not undo them.

This is the layer most feature tables omit and the layer most likely to cause a production incident. Durable agents need idempotency keys, transaction boundaries, reconciliation logs, and compensating actions. Compute lifecycle is not a transaction manager for the outside world.

Product State Matrix, Verified July 23, 2026

The table summarizes current first-party documentation. It is a dated fact sheet rather than a permanent ranking.

Several details deserve extra attention.

Azure exposes two different state models

Azure Container Apps Dynamic Sessions are managed, ephemeral sessions. Requests keep a session allocated. After the cooldown period, the platform destroys it and cleans its resources. A later request can use the same identifier, but it receives a newly allocated session when the old one has gone.

Azure Container Apps Sandboxes are a separate preview resource introduced with explicit lifecycle control. They support memory or disk suspend modes, independent snapshots, and Blob or Data Disk volumes. Combining these two Azure products into one row labeled Azure Sandbox would erase the most important architectural distinction.

Cloudflare separates persistent identity from ephemeral compute state

Cloudflare's architecture uses a Durable Object to own and route a sandbox identity. Its lifecycle documentation states that the local container filesystem, processes, shell state, and interpreter contexts disappear when the container stops after inactivity. The next request starts a fresh container.

keepAlive prevents that sleep transition. It pays for continuity with active resources rather than adding durable storage. For durable files, Cloudflare supports R2, S3, and GCS mounts, including read-only mounts.

Runloop suspend means disk continuity

Runloop's Devbox lifecycle preserves disk during suspend and resume. In-memory state is lost, and daemons need to restart. Independent disk snapshots can seed new Devboxes, while Blueprints provide reusable built environments.

That distinction gives application code a clear job: serialize progress to disk before suspend and make startup idempotent.

Vercel persistence is filesystem persistence

Vercel made Sandbox persistence generally available on May 26, 2026. Current persistence documentation says persistence is enabled by default. Stopping a sandbox snapshots its filesystem, and the next operation resumes a new VM session from the latest snapshot. Setting persistent: false discards the filesystem on stop.

Explicit snapshots capture files and installed packages. Their default retention is 30 days after last use under the rule announced on June 26, 2026. Vercel Drives provide storage independent from a sandbox and support read-only mounts, but the capability was still private beta at the verification date.

E2B and Blaxel preserve memory, with network caveats

E2B persistence saves filesystem and memory on pause, including processes and loaded variables. Its documentation also says clients disconnect during pause. A resumed service may exist in memory while every remote client needs to reconnect.

Blaxel's sandbox lifecycle snapshots processes, memory, and the in-memory filesystem when the environment enters standby. Blaxel explicitly excludes external database connections, message queues, and HTTP pools from reliable continuity. Its volumes survive sandbox destruction and can be mounted read-only.

Docker introduces a host-owned workspace

Docker Sandboxes run agents in isolated microVMs, but their default workspace is a direct mount of the host working tree. The agent can read, write, and delete files there. Stopping the sandbox preserves its VM-owned packages, images, and configuration. Removing it deletes VM contents while host workspace changes remain.

This is a useful counterexample to the phrase everything in the sandbox. Ownership follows the mount, not the path shown to the agent. Docker also warns that saving a sandbox as a template captures its filesystem, including secrets stored there.

External Connections and Side Effects Define the Hard Boundary

Memory restoration can make a process look continuous while the world around it has moved on. Consider an agent that pauses after sending a database update but before recording success locally:

1. The database commits the update.
2. The sandbox pauses or crashes before saving its local checkpoint.
3. Resume restores an earlier memory or disk state.
4. The agent retries the update.

The result depends on the external API. An idempotent operation returns the existing result. A non-idempotent operation can create a duplicate order, message, resource, or payment.

The same pattern appears with Git pushes, queue acknowledgements, object uploads, and webhooks. The recovery design belongs at the external boundary:

• Assign an idempotency key before the first request.
• Record intent and outcome in durable storage outside the sandbox.
• Reconcile uncertain operations after resume.
• Use compensating actions where the external service lacks transactions.
• Re-establish connections and validate session credentials on every resume.

Agent orchestration also needs durable coordination that is distinct from code execution. The Agent Cloud architecture article explains that broader separation. A durable coordinator can remember the task even when its execution sandbox starts clean.

A Repeatable Sandbox State Contract Test

A vendor table is useful for discovery. Production confidence comes from a test against the exact plan, region, SDK version, image, and lifecycle policy you will run.

Create a fixture with five probes:

Run the fixture through every transition your system uses:

create -> sleep -> resume
create -> pause/suspend -> resume
create -> stop/shutdown -> start
create -> crash/timeout -> recover
create -> snapshot -> fork
create -> delete/kill/rm -> verify external state

Capture the result as a versioned contract rather than a one-time note:

provider: example
verified_at: 2026-07-23
sdk_version: 1.2.3
transition: suspend_resume
same_identity: true
process_memory: lost
local_filesystem: preserved
checkpoint: disk_only
external_volume: preserved
connections: reconnect_required
external_effects: reconciled_by_idempotency_key

Repeat the test after SDK upgrades, plan changes, image rebuilds, and provider lifecycle announcements. This is the verification interface for your state architecture.

Keep Write Control as a Separate Axis

Persistence answers how long a change remains. Write control answers who can change which state. A secure design needs both axes.

Cloudflare, Blaxel, and Vercel expose read-only modes for selected external mounts. Docker's default host workspace is writable. E2B secure access authenticates its sandbox controller, which is a different control from a per-directory write allowlist. Runloop provides programmatic filesystem access and network policies. Azure Dynamic Sessions protect their management endpoint and isolate sessions, while the contents of a single session remain available to users of that session.

Evaluate write control at four boundaries:

1. Management plane: who may create, pause, snapshot, or delete an environment.
2. Runtime identity: which OS user and privileges execute agent-generated code.
3. Storage paths: which local roots and external mounts are read-only or writable.
4. Network and credentials: where the agent may send data and how secrets enter the runtime.

For a concrete implementation of runtime identity, filesystem ACLs, and network boundaries, see Codex Windows Sandbox architecture. For the earlier decision about which dependencies may execute at all, see the pre-install trust boundary.

Architecture Rules That Survive Product Changes

The product matrix will age. These rules should age more slowly:

1. Normalize provider verbs into your own state contract. Map every action to the five layers and record observed behavior.
2. Use sandbox-local disk for rebuildable state. Caches, checked-out repositories, dependencies, and temporary artifacts fit naturally.
3. Put durable progress in independently owned storage. A volume, object store, database, or coordinator should carry task state that must survive compute deletion.
4. Design resume as recovery. Reconnect sockets, restart health-checked services, refresh credentials, and reconcile uncertain external operations.
5. Separate continuation from reproducibility. Snapshots continue a particular state. Declarative images and blueprints create known starting states. Mature systems usually need both.
6. Test deletion explicitly. Verify provider-owned state is gone, external data remains only where intended, and credentials captured by snapshots or templates are revoked or absent.

The selection question then becomes precise: which combination of execution isolation, recovery artifact, durable storage, and verification interface matches this workload? That question remains useful even when a provider renames an API or changes its default.

FAQ

What is a persistent sandbox for an AI agent?

A persistent sandbox preserves at least one state layer across compute transitions. The term is incomplete without naming the layer. Filesystem persistence, memory persistence, snapshot retention, and external-volume durability are separate guarantees.

Does a snapshot preserve running processes?

It depends on the snapshot type. E2B snapshots include memory and processes. Runloop documents disk-only snapshots. Vercel snapshots preserve filesystem and installed packages. Verify the provider's current documentation and run a process probe against your configuration.

What survives when a sandbox is deleted?

Provider-owned compute state is normally removed. Independent volumes, object storage, host-mounted workspaces, explicit snapshot artifacts, and external side effects may remain under their own lifecycle rules. Deletion testing should query each owner directly.

What is the difference between a template, snapshot, and volume?

A template or blueprint supplies a reusable starting environment. A snapshot captures a point in time and may resume or fork runtime state. A volume stores files under a lifecycle independent from compute. Provider implementations vary, so use these as architectural categories rather than API synonyms.

Can memory persistence keep database connections alive?

Local socket objects may return with memory, while the remote database may have closed its side of the connection. Treat all external connections as reconnect-required and make operations safe to retry.

How should I compare AI agent sandbox providers?

Start with workload requirements for isolation, local disk, process continuity, recovery time, external storage, write controls, retention, and deletion. Then run the same state-contract fixture against each provider. Price and startup speed matter after the state and security contracts fit.

References

• Microsoft Learn, Dynamic sessions in Azure Container Apps, verified July 23, 2026.
• Microsoft Learn, Use dynamic sessions in Azure Container Apps, updated April 6, 2026.
• Microsoft Learn, Azure Container Apps Sandboxes overview, preview documentation updated July 20, 2026.
• Microsoft Learn, Snapshots and state management for Azure Container Apps Sandboxes, preview documentation.
• Cloudflare, Sandbox lifecycle, updated May 27, 2026.
• Cloudflare, Sandbox storage mounts, updated June 8, 2026.
• Runloop, The Devbox Lifecycle, verified July 23, 2026.
• Runloop, Devbox Snapshots, verified July 23, 2026.
• Vercel, How Sandbox duration and persistence work, updated June 29, 2026.
• Vercel, Snapshots, verified July 23, 2026.
• Vercel, Drives for Vercel Sandbox in Private Beta, June 5, 2026.
• E2B, Sandbox persistence, verified July 23, 2026.
• E2B, Sandbox snapshots, verified July 23, 2026.
• Blaxel, Sandboxes, last modified May 2026.
• Blaxel, Volumes for sandboxes, last modified May 14, 2026.
• Docker, Docker Sandboxes usage, verified July 23, 2026.
• Docker, Default security posture, verified July 23, 2026.
• Docker, Sandbox templates, Early Access documentation verified July 23, 2026.