Your agent is waiting for approval. What happens to its computer?

An agent reaches the dangerous step and stops. It has prepared a database migration, opened the production diff, and asked a human to approve the change. The answer might arrive in thirty seconds. It might arrive tomorrow morning.

What happens to the agent's computer while nobody is looking?

This is where “persistent sandbox” stops being a useful category. Every provider can keep files. Far fewer can freeze a live machine and return the agent to the same process, terminal, browser, and in-memory state. Some call a disk restore “resume.” Others preserve memory but only on a particular runtime class or through a beta API.

For human-in-the-loop agents, those differences determine whether approval continues the task or starts a recovery procedure.

The state an approval interrupts

A real agent rarely waits at a clean process boundary. At the moment it asks for approval, it may have:

• a shell positioned in the relevant working directory;
• an agent process holding conversation and tool state in memory;
• a browser logged into a development environment;
• a dev server, database, or queue running in the background;
• a debugger stopped on the line that explains the bug;
• unflushed application state or a half-complete build;
• an attached terminal that a human expects to reopen.

The repository on disk is only one layer of that state. A provider that saves the filesystem but discards memory gives you the files back, but not the running investigation.

What the lifecycle words should mean

Providers use similar words for materially different operations:

• Stop and start normally preserve a disk while rebooting the environment. Processes end and memory is cleared.
• Pause and resume should freeze memory and running processes, then continue them later.
• Snapshot and restore may capture only a filesystem, or it may capture memory too. Restoration may continue the same sandbox or create a new one.
• Standby usually means the provider automatically suspends an idle sandbox and wakes it on the next connection.

The API name is not the guarantee. The useful questions are whether RAM is saved, whether processes return, whether the transition is under your application's control, and what retention or runtime-class restrictions apply.

Six providers at a glance

✅ means the platform directly supports the requirement. ⚠️ means it is beta, alpha, automatic rather than explicit, or limited to certain runtime classes. ❌ means the relevant live state is not preserved.

The final column asks a narrow question: can an application suspend an agent at an arbitrary approval point and later continue its live work without designing every process to reconstruct itself?

Freestyle: explicit whole-machine pause

Freestyle's pause operation freezes a VM and saves its memory. Starting it again resumes the same processes at the same point, with open files and in-memory state intact. The transition is explicit: your orchestrator decides when to call pause() and start(). An idle timeout can apply the same behavior automatically.

Pause and resume both finish in the low tens of milliseconds even in slow cases. To a user, that feels instant. Combined with releasing active CPU and memory while the VM is paused, it makes suspension cheap enough to use routinely across a large fleet: pause at every approval or idle gap, then continue without a cold boot when work returns.

Interactive sessions are part of the machine rather than a separate disposable command runner. PTY processes freeze with the VM; after the VM starts, a client can attach to the same session again. That is useful when an approval request links a human back to the exact terminal where the agent stopped.

A paused VM releases its compute reservation and does not count against the concurrent-VM limit, although its saved memory and disk still occupy storage. There is also a distinct stopped state for workflows that intentionally want a fresh boot. The API does not blur disk persistence and live-state persistence into one operation.

For approval workflows, that makes the orchestration simple: pause after emitting the request, persist the VM ID with the approval record, then start and reattach when the decision arrives.

Blaxel: excellent automatic standby, less explicit control

Blaxel sandboxes automatically enter standby after roughly fifteen seconds without an active connection. The standby snapshot preserves the filesystem and running processes, and the sandbox resumes on reconnection. Blaxel documents resume times under 25 milliseconds.

That is a strong fit when the product naturally maps user presence to a connection. The machine goes quiet when the interface disconnects and wakes when the user returns. The important limitation is control shape: Blaxel does not expose built-in start and stop functions for standby. Applications influence it through connections, activity, and process keep-alive behavior rather than placing an explicit checkpoint at the exact approval boundary.

Blaxel also notes that external connections are not preserved. The local process returns, but a database pool, message queue connection, or HTTP keep-alive may be stale and must reconnect. That caveat is normal for suspended computers—the remote service was never frozen.

E2B: memory persistence behind a beta lifecycle

E2B says paused sandboxes can preserve filesystem and memory state, and reconnecting to a paused sandbox resumes it. That gives it the important primitive: an agent does not necessarily have to rebuild its runtime after waiting.

The pause surface is still marked beta in the E2B SDK. An application adopting it should treat method names and behavior as a moving integration boundary, and separately account for the active-duration and retention rules of its plan.

For a prototype or an application comfortable depending on a beta lifecycle, this is a credible approval workflow. It is less conservative than building a durable orchestration system around filesystem-only recovery, but it does not yet present the same stable, explicit contract as Freestyle's VM lifecycle.

Daytona: capable, if you choose the right sandbox class

Daytona makes the disk-versus-memory distinction unusually clear. Linux VM and Windows sandboxes support pause and resume, preserving both filesystem and memory while releasing CPU. They can also create hot snapshots containing memory.

Container and GPU sandboxes do not support that lifecycle. Stopping them preserves either the filesystem or externally mounted results, but clears memory. The same SDK name can therefore describe two very different approval experiences.

Daytona is a good option when the application deliberately selects a VM sandbox for interactive work. It is only a conditional check in the table because “we use Daytona” does not by itself guarantee that an interrupted process will return.

Modal: an experimental checkpoint, not ordinary pause

Modal's standard Sandbox lifecycle has a maximum active duration of 24 hours. For longer-lived state, it directs users toward snapshots. Filesystem snapshots preserve files; an alpha memory-snapshot feature can create a new Sandbox with the original memory, filesystem, and processes.

The memory path has meaningful restrictions. Snapshots expire after seven days, taking one currently terminates the original Sandbox, open connections close, and a Sandbox cannot be snapshotted while an exec command is still running. Modal also warns that background processes launched from Sandbox.exec are not properly restored.

That can still be valuable for reproducible experiments and prepared runtimes. It is a poor primitive for blindly freezing an agent at whichever line happens to require human approval. The orchestrator has to arrange a safe checkpoint rather than suspending arbitrary live work.

Box by ASCII: persistent disk, fresh process state

Box does not take a memory snapshot when it stops. box stop saves the disk only. It creates a filesystem snapshot, not a machine snapshot: memory and hand-run processes are discarded, and resuming takes a few seconds.

Files, installed packages, and enabled systemd services survive. The live state this article is about does not. Docker build cache also does not return. A shell command, agent loop, debugger, or development process that was live at approval time is gone unless the application arranged for a service manager and durable state to reconstruct it.

Box is limited to workloads where every process is disposable and the filesystem is the only state that matters. Its stop/resume API is not a live checkpoint. For approval-bound agents, it creates recovery work precisely when a human expects to continue.

Memory preservation is not magic

Even the strongest pause cannot freeze the rest of the world. Remote databases expire sessions. OAuth tokens can lapse. Locks may time out. WebSockets close. Approval workflows should expect external connections to be re-established and should validate that the approved action still applies to current state.

The difference is how much local reconstruction remains. Reopening a database connection from an intact process is different from rebooting a machine, restarting the agent, recreating its terminal, recovering its conversation, and hoping every important fact reached disk.

An approval boundary should also be explicit in application state. Store the request, the proposed action, the resource ID, and an idempotency key outside the sandbox. A memory snapshot preserves execution context; it does not replace a durable record of what a human approved.

Choose for the interruption, not the happy path

If an agent only runs short, restartable commands, every provider here can preserve enough state. Files on disk and a durable queue may be all the application needs. Box is limited to that narrower model; Modal's filesystem snapshots may also be sufficient when richer lifecycle semantics are unnecessary.

If the product includes long investigations, interactive terminals, browsers, debuggers, or approvals that arrive at arbitrary times, filesystem persistence is not the same product. Blaxel offers a compelling automatic standby model. E2B and Modal expose memory preservation with maturity caveats. Daytona supports it well on the VM classes that implement pause. Freestyle provides the most direct general-purpose contract: explicitly freeze the whole computer, release compute, and return to the same live state when the human is ready.

The practical test is one sentence: after approval, does your agent continue—or recover?