Guide
Top Tools for Building an AI Coding Agent Sandbox
Handing a coding agent the ability to run its own code means picking an isolation boundary for it. The right one depends on whether you are building a product or just running an agent on your own machine.
The tools for sandboxing an AI coding agent split into three groups. Hosted microVM and container platforms, led by E2B, Modal, Daytona and Vercel Sandbox, give you a dedicated kernel per task and are built for products that run other people's generated code at scale. Built-in sandboxes inside Claude Code and GitHub Copilot use OS-level mechanisms, Seatbelt on macOS and bubblewrap on Linux, and need no separate infrastructure for a developer running an agent locally. Container runtimes like Docker sit in between: faster and cheaper than a microVM, but sharing a kernel with the host, which is why they are considered too weak for untrusted, multi-tenant code.
Why an AI coding agent needs a boundary at all
A coding agent that can run its own code is also a program that can run any code, including code it hallucinated. On your own machine it runs with your user permissions, so a bad command is not limited to a typo in a test file. It can delete the wrong directory or read a credential it had no reason to touch.
A sandbox puts a wall around where that code runs. If the agent's command does something destructive, the damage stops at the sandbox and the sandbox gets thrown away. This matters whether you are one developer running an agent against your own project, or a company letting thousands of users trigger an agent that writes and runs code on their behalf.
Those are different problems with different right answers. One person, one trusted agent, one machine, calls for something lightweight. A product serving strangers' prompts calls for the strongest isolation you can afford, because you no longer know in advance what the code is going to try.
- An unsandboxed agent runs destructive commands with your full user permissions.
- A sandbox contains the blast radius and gets discarded after use.
- A single trusted user and a multi-tenant product need different strength of isolation.
Hosted microVM platforms: E2B, Modal, Daytona, Vercel
E2B runs each sandbox as its own Firecracker microVM, AWS's own virtualization technology, giving every task a dedicated kernel rather than a shared one. It is built for sub-200ms cold starts and supports pause and resume, which saves both filesystem and memory state so a long task can pick back up instead of starting from zero. Its Hobby tier is free, capped at a one-hour session and 20 concurrent sandboxes; the Pro tier runs 150 US dollars a month for 24-hour sessions and 100 concurrent sandboxes.
Modal added Sandboxes in 2024 on top of its existing serverless platform, and isolates them with gVisor, Google's open-source container runtime. gVisor runs an application kernel in user space that intercepts every system call the sandboxed code makes, so the host kernel never sees most of them directly. Modal advertises cold starts under one second and has been used at well over 100,000 concurrent sandboxes, which is the scale argument for picking it over a slower microVM when you need raw throughput.
Daytona and Vercel Sandbox both also run on Firecracker microVMs, but aim at different users. Daytona is open source under the Apache 2.0 license and built around the Dev Container standard, so you define an environment once and run it locally or on a server you control. Vercel Sandbox is usage-billed by active CPU time, 0.128 US dollars per vCPU-hour, and ties naturally into a Vercel-deployed app, but sessions on its Pro plan are capped at five hours and it runs out of a single region.
- E2B: Firecracker microVMs, sub-200ms starts, pause and resume; Hobby free, Pro $150/mo.
- Modal: gVisor isolation, sub-second starts, built for very high concurrency.
- Daytona: Apache 2.0, Dev Container standard, runs locally or self-hosted.
- Vercel Sandbox: Firecracker microVMs, billed by active CPU time, Pro capped at 5-hour sessions.
Built-in sandboxes: Claude Code and GitHub Copilot
You do not always need a hosted platform. Claude Code ships its own sandbox for the Bash tool: Seatbelt on macOS, bubblewrap plus seccomp on Linux and WSL2. You declare which files and network domains a command may touch, and the operating system enforces it for every shell command and the processes it starts, which is what lets Claude run commands without stopping to ask permission for each one.
GitHub Copilot's sandboxing reached public preview in June 2026, and it works two ways. Local sandboxing wraps commands in an OS-level boundary built on Microsoft's own eXecution Container: Seatbelt on macOS, Bubblewrap on Linux, ProcessContainer on Windows Insiders builds. Cloud sandboxing moves the whole session off your machine into a GitHub-hosted, ephemeral Linux environment built on Azure Container Apps. Neither is on by default: you turn on local sandboxing with /sandbox enable inside a session, or launch a cloud one with copilot --cloud.
Both of these are the right call for one developer running an agent against their own repository. They need no account with a sandbox vendor and no infrastructure to operate, and the isolation is strong enough to stop an agent from wandering outside the project or the network boundary you set. What they are not built for is running strangers' code at the scale a hosted microVM product targets.
- Claude Code's Bash sandbox: Seatbelt on macOS, bubblewrap plus seccomp on Linux and WSL2.
- GitHub Copilot sandboxing (public preview, June 2026): local via Microsoft's MXC, or cloud via Azure Container Apps.
- Both require you to turn them on; neither is enabled by default.
- Built for a single trusted developer, not for multi-tenant, untrusted code.
Cloudflare Sandbox, and why it is not just a worker
Cloudflare's Sandbox SDK is easy to mistake for a lightweight, isolate-based product because it is built on Cloudflare Workers. It is not. Each sandbox is a full Ubuntu Linux VM, provisioned through Cloudflare's Containers product and kept alive by a Durable Object that gives it a persistent identity. Workers handle your application logic; the actual code execution happens inside the VM, with its own filesystem, process table and network stack, isolated from every other sandbox running alongside it.
Cloudflare is also one of the seven hosted providers that plug directly into OpenAI's Agents SDK since its April 2026 sandbox update, alongside Daytona, E2B, Modal, Vercel and others. That makes it a reasonable default if your agent is already built on that SDK and you want one less integration to write, rather than a pick based on raw latency.
The tradeoff against a microVM platform like E2B is less about speed and more about ecosystem. If your application already runs on Cloudflare's edge, keeping the sandbox there avoids a second vendor and a second network hop. If it does not, there is no particular reason to pick it over a provider with no edge platform attached.
- Each Cloudflare sandbox is a full VM, not a lightweight Worker isolate.
- Durable Objects give each sandbox a persistent identity; Containers run the actual Linux VM.
- Cloudflare is one of the OpenAI Agents SDK's officially integrated hosted providers.
- The main case for it is already being on Cloudflare's platform, not raw performance.
Where a plain Docker container still fits
Docker containers share the host's kernel through Linux namespaces and cgroups, which is faster to start and cheaper to run than a microVM, but it is also why a container escape is a live concern in a way it is not for Firecracker or gVisor. A kernel bug reachable from inside the container can reach the host directly.
For a single developer who trusts their own agent and just wants a disposable, reproducible environment, that risk is usually acceptable, and a container is the simplest tool that does the job. For a product that runs generated code from the public, most of the hosted platforms above exist specifically because a shared kernel is considered too weak a boundary for that case.
The rule of thumb that has held up: use a container when you are the only one feeding it code, and reach for a microVM or gVisor-based platform the moment someone else's prompt decides what gets executed.
- Containers share the host kernel; a kernel exploit can reach past the container.
- That is an acceptable risk for your own trusted agent, less so for anyone else's input.
- Hosted microVM platforms exist mainly to remove that shared-kernel risk at scale.
Picking between them for your own project
If you are shipping a product that runs AI-generated code for other people, the decision is mostly about scale and budget: Modal if you need very high concurrency, E2B if you want fast, stateful sessions with a mature SDK, Daytona if you want to self-host and avoid per-second billing, Cloudflare if you are already on that platform.
If you are a developer running an agent against your own codebase, you likely do not need any of the above. The sandbox built into Claude Code or Copilot already stops the agent from wandering outside the files and domains you allow, and it costs nothing extra to turn on.
The one thing worth checking regardless of which you pick is what happens to your secrets. A sandbox contains code execution. It does not, by itself, decide whether an API key sitting in your project folder is something the agent should be able to read.
- Multi-tenant product: pick a hosted microVM or gVisor platform by scale and budget.
- Single developer, own codebase: the built-in Claude Code or Copilot sandbox is usually enough.
- Sandboxing code execution and protecting secrets are two separate problems.
How Forkbench sits outside this comparison
Forkbench does not belong on the list above, and it is worth saying why rather than squeezing it in as a smaller competitor. It is a desktop app that runs your coding agent, whichever vendor you use, in a real terminal on your own Mac. It is not a code-execution sandbox: it does not give the agent a separate kernel or a disposable filesystem the way E2B or Modal do.
What it adds on top of whichever sandbox, if any, you are already using is supervision and secrets handling for a workflow running on your own machine. A folder lock can confine the agent to the project directory you approved, though that lock is opt-in and, unlike a microVM, it does not touch the network: an agent inside it can still make an outbound request.
Its Vault keeps API keys in the macOS Keychain and hands them to a command by name instead of printing the value into the agent's context. That keeps a key out of the conversation and out of a plain file, but it is not a sandbox boundary either: whatever program the agent runs with that key still gets to use it, pinned or not. If you need to stop an agent's generated code from reaching your production systems at all, that is the job of one of the tools above, not of Forkbench.
- Forkbench runs an agent locally; it is not a code-execution sandbox like the tools above.
- Its folder lock is opt-in and does not restrict the network.
- Its Vault hides a key's value from the agent, not from the program the agent is allowed to run.
Related: Forkbench as an E2B alternative, Forkbench vs Docker sandboxes, Sandboxing coding agents with macOS Seatbelt, How Forkbench handles your data
Frequently asked
What is the best sandbox for running untrusted, AI-generated code at scale?
Modal and E2B are the two most commonly cited for scale: Modal for very high concurrency with gVisor isolation, E2B for fast, stateful Firecracker microVM sessions with a mature SDK. Daytona and Vercel Sandbox are the other two Firecracker-based options worth comparing.
Is Docker secure enough to run AI agent code?
A Docker container shares the host's kernel, so it is weaker than a microVM or gVisor-based sandbox. It is usually fine for your own trusted agent on your own project, but most products that run strangers' generated code use a stronger boundary instead.
Does Claude Code's sandbox work the same way as Cloudflare's?
No. Claude Code's sandbox restricts a shell command's file and network access on your own machine using Seatbelt or bubblewrap. Cloudflare's Sandbox SDK runs your code in a separate, fully isolated Linux VM in Cloudflare's cloud. They solve the same problem at different scales.
Does GitHub Copilot sandbox agent sessions by default?
No. Copilot's sandboxing, in public preview since June 2026, has to be turned on with /sandbox enable for local sandboxing or copilot --cloud for a cloud session. It is not automatic.
Can Forkbench replace one of these sandbox tools?
No. Forkbench supervises a coding agent in a terminal on your Mac and protects secrets with its Vault, but it does not give the agent a separate kernel or filesystem. For containing untrusted, AI-generated code, a platform like E2B, Modal or Daytona is the right tool.