We previously wrote an article discussing why coding agents need a sandbox. Now we want to push the discussion one step further: across different development steps, how do you choose a specific sandbox runtime?
Among these products that all call themselves sandboxes, even after confirming that isolation satisfies the task’s security risk requirements, we still need to distinguish what remains after the environment shuts down, to what extent outbound write operations can be constrained, and who records the task’s progress. To untangle these choices, we can follow a concrete bug-fix task.
The task has four steps: the agent needs to run
npm install to set up dependencies, run
npm test to verify the tests pass, modify code in a private
workspace, then pause and wait for developer review, and finally push
the fixed branch to GitHub.
When running tests, you need to prevent unknown test scripts from damaging the host system. While waiting for review, the developer wants the work already done to survive even if the runtime environment shuts down. When pushing the branch, you need to constrain unexpected changes to the remote repository. These three concrete problems map directly to different choices when selecting a sandbox: how to isolate execution, how to recover progress, and how to constrain outbound operations.
The agent ran npm install the previous day and modified
several files. To wait for developer review, the runtime environment was
shut down overnight. The next morning, the agent is ready to continue
working.
At this point, we face a question: after the runtime environment shuts down, can we recover the files that were modified the day before?
In Azure Dynamic Sessions, the session is destroyed after the cooldown period ends, and the locally saved temporary workspace and dependency files are cleared along with it. This means when the task restarts the next day, the local development environment needs to be rebuilt from scratch.
In Cloudflare Sandbox, the platform uses Durable Objects to manage a sandbox’s identity and lifecycle. As long as the dedicated compute container remains active, local files, running processes, and environment variables persist. However, once the dedicated container stops running, the existing public documentation makes no commitment to recovering those files.
If the platform can retain our modified files, we face the next question: do we only need to recover files on disk, or do we also need to bring back running programs and memory state?
If only disk files need to be recovered, Runloop saves disk state when suspending a sandbox, and also preserves instance IDs and SSH keys, but does not save memory. When the sandbox is brought back up, previously running programs and daemons need to be restarted. In Vercel Sandbox, stopping a sandbox saves a snapshot of the filesystem and configuration. The next session starts from that snapshot, but recovering the memory of running programs falls outside the platform’s commitments.
If both memory and running processes need to be recovered, E2B provides a persistence mechanism that can save filesystem and memory state on pause, including running processes and loaded variables, and only permanently deletes the sandbox and its saved state when a kill command is issued. Blaxel, when a sandbox is in standby, also preserves the filesystem and running processes. However, external network connections do not automatically reconnect after the sandbox resumes.
Even when both disk files and running processes are recovered, we still need to consider one last question: what state cannot be preserved by the sandbox and must be handled externally? For example, a sandbox cannot recover expired temporary access credentials, nor can it remember the approval status of a manual review. The system still needs to record and manage this task progress and approval information outside the sandbox.
After local npm test passes, the agent needs to push the
modified code branch to GitHub. To protect this push process, in Docker
Sandboxes, we can see some concrete isolation mechanisms.
If we use direct mode, the sandbox runs on a private Docker Engine,
and all modifications act directly on the host’s current working
directory. To use an isolated private workspace, we need to explicitly
add the --clone flag when creating the sandbox, editing
inside a copy within the virtual machine.
When executing push commands, the sandbox at the network layer blocks all non-HTTP/HTTPS protocol access by default. Even for ordinary HTTP/HTTPS requests, the proxy server denies access by default. For identity credentials, the sandbox stores tokens on the host side, keeping them out of the sandbox’s filesystem or environment variables. Only when the sent request satisfies the security policy does the host-side proxy inject the token into the request headers.
However, merely hiding the token does not mean the sandbox only permits the specific write operations needed for this bug fix. When the agent is ready to push code, we can perform three layers of security checks, from broad to narrow:
github.com. This can intercept
traffic to unknown servers, but the proxy itself cannot distinguish
whether the agent is pushing the current fix branch or performing some
other write operation.That said, the product materials we’ve seen so far do not provide a general-purpose control scheme that can automatically understand task intent. If the credential injected by the proxy carries overly broad permissions, unintended modifications can still occur even with the token hidden.
When the agent is modifying code or pushing a branch, if it pauses for some reason mid-task, or if execution times out and is interrupted, the sandbox itself, even if it can recover disk and processes, cannot decide what the task should do next. At this point, we need a control program that can invoke models, select tools, record execution progress, and handle retries — this is the Harness.
We need to decide whether the team runs and maintains this control program themselves, or delegates it to an external platform.
If the team chooses to self-host, they can build their own or integrate existing queues, task checkpoints, approval flows, and retry logic, with the sandbox serving only as an isolated container within that system.
If they choose a managed platform, these control and coordination responsibilities are handed over to the vendor. For example, in Claude Managed Agents, Anthropic manages the entire agent loop on their managed cloud and persists session history, sandbox state, and execution output server-side. Because these session states are managed in the cloud, the service currently cannot use Zero Data Retention contracts. If the self-hosted model is chosen, code execution capability depends on the locally deployed environment configuration.
By contrast, AWS Bedrock AgentCore demonstrates a different decomposition approach. In this framework, the Code Interpreter provides an isolated execution environment, Identity handles portions of authentication and external access control, Runtime is used for deploying custom frameworks, and the Harness component is separated out, specifically responsible for model orchestration, tool invocation, context memory, and generating the final response.
Back to that bug-fix task we started with. When the modified branch is finally pushed back to GitHub, the entire bug-fix effort comes to a close. In building this kind of development assistance system, providing an isolated runtime container is becoming a universal baseline, but the concrete implementation above that baseline still determines how the system operates. For integration and migration of the entire system, the real engineering pain points often center on how the workspace is recovered, how external write permissions are constrained, and where vendor-managed task progress connects with local logic.
In selection and decision-making, only after we’ve clarified what can be recovered after the environment shuts down, which operations are permitted when writing to GitHub, and who remembers the task’s progress — and only after we’ve identified the specific decision path — does measuring and comparing cold-start latency, rebuild speed, or P50/P95 performance metrics become practically meaningful. Without this, comparing raw speed numbers across different decision paths is unlikely to yield conclusions that guide implementation.