How Sandbox State Survives Agent Restarts Without a Database

Sandbox state can survive agent restarts without a database when the runtime preserves the execution environment. Full-context snapshots can capture files, memory, and running processes, so the infrastructure can provide durability without the application having to build it. The qualification matters just as much as the promise. Runtimes differ in which kinds of state they keep, and none can undo external effects just by restoring a snapshot.

Why agent state dies between sessions and why the usual fix creates new problems

An agent that executes code across interactions accumulates a working environment. Installed dependencies, cloned repositories, conversation history, and mid-task progress all assume that earlier work remains available. But memory belongs to a process, so it disappears when that process exits. Container scratch files can disappear when the container is rebuilt or rescheduled. Unhandled exceptions, out-of-memory kills, deploys, host reboots, and cloud instance recycling make those interruptions routine production conditions.

The usual response is to put state outside the process. Each session reads its context, performs work, writes results, and exits, simulating continuity through external storage. Yet conversation history, working files, large artifacts, and semantic memory have different storage needs, including databases, volumes, object stores, and vector services. The agent must serialize the right context, reload it on every boot, and keep the stores consistent. Application code remains responsible for knowing what to save, where to save it, and how to reconstruct a usable environment.

What full-context snapshotting captures that external stores cannot

A full-context snapshot preserves the execution context rather than only the data an application chose to export. That context includes the filesystem, memory, and running processes. It also includes loaded environment variables, shell state, installed packages and their configuration, and scratch files that the agent never explicitly checkpointed. Background processes keep their in-memory state when the runtime provides full-process preservation. The object being saved is a working runtime.

That distinction changes what resumption means. An agent reading from a database starts with serialized data and reconstructs the environment needed to use it. A full-runtime restore starts from the captured machine state, without reinstalling dependencies or rebuilding that context. Conversation memory, task queues, generated artifacts, and progress markers can stay together in that captured machine state even though they do different jobs. A half-formed variable may be disposable while a three-hour research run is not, but a full snapshot can capture both without application code classifying each item first. The durability decision moves from the agent’s save logic to the runtime’s lifecycle.

Three distinct mechanisms platforms use to preserve runtime state

Runtime persistence has several implementations, with three distinct mechanisms represented here. Snapshot-on-pause captures the runtime when a sandbox becomes inactive and places it in dormant standby. Blaxel describes this model as preserving the filesystem, memory, and running processes through indefinite hibernation. Compute billing stops during standby, while snapshot storage remains billable. Resumption restores the captured environment.

Continuous filesystem sync takes a different route. Sprite syncs filesystem changes to durable backing storage, so file survival does not require an explicit snapshot operation. An installed model SDK or test harness is present on the next run. The environment pauses when unused, compute billing stops, and a warm resume brings it back with processes still in place.

Change-based checkpoint/restore works with what has changed in the captured state. Dong et al.’s May 2026 DeltaBox paper describes DeltaFS organizing file states into layers, freezing the writable layer, and inserting a new one at checkpoint time. Rollback becomes a layer switch. Its coupled process mechanism, DeltaCR, uses incremental dumps and accelerates rollback by forking directly from a frozen template process. These approaches all move preservation into the runtime, but their practical differences turn on what survives and how long preservation and resumption take.

What actually survives a pause and what does not, across approaches

“Stateful” is not a binary property. Filesystem preservation is the broadest guarantee, while process memory may survive only a warm pause within a platform-defined window. A cold wake after a longer idle period can discard that memory. GPU state is generally excluded from snapshotting, and background processes launched through command execution may not return even where a platform describes process survival.

Microsoft’s Foundry Hosted Agents illustrate a filesystem-centered model. Microsoft documents persistence for $HOME and /files across turns and idle periods, while compute and other state are deprovisioned on idle. Important working data belongs in the durable filesystem, but processes still need a graceful restart to carry on. Vercel’s GA persistence model, shipped May 26, 2026, likewise automatically snapshots filesystem state when a sandbox stops. A fresh session resumes through the same named handle, but snapshotting terminates the sandbox and does not preserve running-process memory or restore background processes launched through command execution.

These guarantees define how much recovery logic remains in the application. Agent developers still need a cold-wake baseline that can handle incomplete work and reload the working state that was actually preserved. With a durable filesystem, that logic can skip file recovery, but it still needs to handle process initialization.

Why latency from sandbox operations compounds across agent tool-call chains

A single request may invoke a sandbox several times in sequence. Each invocation that needs a cold start or reconstruction adds another delay before useful work begins. Reading context from a database, reinstalling dependencies, or loading a vector index can extend that delay.

With full-runtime resumption, the environment already holds the state the agent left behind, so there is no need to rebuild it. With filesystem-only persistence, files and installed packages stay in place, though processes may still need to start. This distinction makes survival guarantees part of both the performance model and the recovery model. Sub-second warm resume matters most when a user has to wait each time they interact with the agent.

Fast resume also changes the cost of waiting. A dormant sandbox can retain captured state without consuming active compute. In Blaxel’s standby model, snapshot storage replaces idle compute billing, and resumption replaces keeping a process permanently active.

Why isolation is a prerequisite for making persisted state trustworthy

Preserving an environment is valuable only if that environment has a trustworthy boundary. Agent-written code is untrusted because of how it is made, even if it has no bug. Containers share the host kernel, so a kernel exploit can expose the host or other tenants. MicroVMs give each workload its own kernel under hardware virtualization, placing a stronger boundary around that execution.

The recommended “brain outside, hands inside” architecture follows from that threat model. The agent loop and secrets remain outside the execution sandbox, while outbound access goes through an allowlist. Dangerous commands should not run in the same place that holds the agent’s credentials, memory, and continuity. This separates durable decision-making from the environment in which untrusted code acts.

The execution boundary also needs controlled filesystem persistence, an unprivileged process, and CPU and memory limits. Those controls cover different ways a workload can affect resources outside the scope it was meant to have. Snapshotting should preserve state within that boundary. Without isolation, durability can preserve a liability.

The checkpoint/restore vulnerability: when resuming to a prior state is semantically unsafe

If an agent calls an API, writes to an external database, or sends a message before an interruption, returning to an earlier checkpoint does not undo that action. The restored agent may execute it again. An internally accurate snapshot can therefore produce an externally incorrect continuation.

The August 2026 paper “Safe to Resume? Breaking Execution Continuity of Agent Execution via Rollback” examines execution-continuity vulnerabilities introduced by checkpoint/restore. This is a correctness objection. DeltaBox’s low-latency checkpoint and rollback mechanism does not, by itself, establish that repeating work is safe. Whether repeating work is safe depends on what occurred outside the captured environment.

Developers should treat external effects as potentially non-idempotent and add code that handles deduplication or at-least-once execution. Keeping decision logic outside the sandbox helps distinguish restored execution state from actions that have already committed. A durable workflow layer can track those commitments while the sandbox preserves the environment. Checkpoints at boundaries where resumption is known to be safe can reduce exposure, but checkpointing alone does not establish that safety. Runtime snapshotting handles the infrastructure layer. The agent developer remains responsible for idempotency at the application layer.

What the API surface for sandbox-native persistence looks like in practice

When the runtime handles persistence, application code can use lifecycle operations without having to build a separate state-management system. Vercel’s GA API, shipped May 26, 2026, provides a concrete example. Sandbox.create() enables persistence by default without additional configuration. Sandbox.get() retrieves a stopped sandbox by name and resumes it automatically. sandbox.update() changes mutable parameters, including persistence, after creation.

The remaining lifecycle methods include fork(), getOrCreate(), and delete(). The hooks onCreate and onResume give application code places for startup and rehydration logic. That distinction reflects Vercel’s filesystem-only preservation guarantee. A short persistence API removes storage plumbing without promising that all initialization disappears.

Forking also makes preserved state useful beyond recovery. It enables parallel agent exploration from a known good baseline without losing that starting point. In a separate implementation, Dong et al.’s DeltaBox paper reports checkpoint and rollback latency of 14 ms and 5 ms respectively, which lets agents explore far more exploration nodes in the same amount of time. That result illustrates why preserving state can support exploration as well as continuity. The application no longer needs custom serialization and reconstruction for the working state the runtime guarantees to preserve.

How to decide which persistence mechanism fits a given agent workload

The decision begins with task duration, sensitivity to resume latency, and the need to isolate untrusted code. For short interactive sessions, repeated resume delays dominate the user’s experience. Warm-pause models with sub-second resume are an appropriate fit. Filesystem-only survival may be sufficient when sessions do not accumulate deeply stateful process memory. The requirement is fast access to the state the next tool call actually needs.

For background tasks that run for hours to days, the cost of waiting can affect the choice of persistence mechanism more than how fast they respond. Perpetual standby avoids compute charges while the agent waits, with snapshot storage as the trade-off. Agents executing unreviewed AI-generated code need microVM isolation as a baseline before comparing persistence behavior. Enterprise evaluation may also impose requirements including SOC 2, HIPAA, GDPR, and ISO 27001.

External effects add a separate decision axis. Long tasks that call APIs, write to databases, or send messages need application-level idempotency even if all of their runtime state survives. Pairing a durable workflow layer with a stateful sandbox separates commitment tracking from environment preservation. Semantics-aware checkpoint placement can reduce rollback risk, but it does not replace reasoning about safe replay. Treat persistence as infrastructure by choosing a runtime whose survival guarantee fits the workload, then write agent logic against that guarantee.