How to Sandbox AI-Generated Code, Local or Cloud

The real question behind sandbox AI code

Every AI coding tool eventually runs a command: installing a package, executing a test, running the script it just wrote. Sandbox AI code is the question of where that command actually executes, and it's the same question whether the tool is Claude Code, Codex, Cursor, Gemini CLI, or a script you wrote yourself around a model's API.

There are two broad answers: keep it on your own machine inside a stronger boundary than the one your shell gives it by default, or hand it to a service built to isolate code at scale. Neither is universally right. The decision comes down to whether the code might be adversarial, how many of these tasks you're running, and whether you're willing to operate the isolation layer yourself.

• Local sandboxing: a stronger boundary on your own machine, no extra bill.
• Cloud sandboxing: someone else operates the isolation layer, usually billed per task or per minute.
• Neither checks whether the code is correct, only where it runs.

Local sandboxing: what actually isolates code on your own machine

A disposable virtual machine is the strongest local boundary, because the AI-written code never touches your host's kernel at all. On any OS this means running a throwaway Linux VM and treating it as single-use: start it, run the task, delete it.

A container is the lighter-weight option, but a default container is not the same as an isolated one. A standard Docker container shares your host's kernel, so a kernel exploit inside it can reach your machine. Running the same container through gVisor, the open-source sandbox Google maintains that intercepts every system call and enforces the boundary from user space, closes most of that gap: add --runtime=runsc to the run command instead of using the default runtime. A Firecracker-based setup goes further still, giving the container its own lightweight virtual machine; Firecracker is the microVM technology Amazon built for Lambda, and it is also what several hosted AI sandbox providers run underneath.

Whichever you pick, the operating system itself can add a second layer. macOS has Seatbelt, Windows has Windows Sandbox, a disposable desktop VM built into Windows 10 and 11 Pro and Enterprise, and Linux has namespaces and seccomp. These are worth stacking on top of a VM or container, not a replacement for one.

• Strongest: a disposable VM; the code never touches your host kernel.
• Stronger container: run it with --runtime=runsc (gVisor) instead of Docker's default runtime.
• Strongest container: a Firecracker-based microVM, the same technology AWS Lambda runs on.
• Layer the OS sandbox on top: Seatbelt on macOS, Windows Sandbox on Windows, namespaces and seccomp on Linux.

A sandbox you can build in the next ten minutes

You don't need a hosted account to start. If you already have Docker installed, the fastest meaningful upgrade is switching its runtime. Install gVisor, then run your agent's command with docker run --runtime=runsc --network none --cap-drop=ALL -v $(pwd):/workspace, followed by your image and command. The --network none flag means the task cannot reach the internet at all unless you explicitly allow a host; add one back only if a step genuinely needs it, such as installing a package.

If you don't want Docker in the loop, a disposable Linux VM gets you a comparable boundary with less tuning: create one, mount only the project folder into it, run the agent's command inside, and delete the VM when the task is done.

Either way, test the boundary before you trust it. Have the sandboxed process try to read a file outside the project folder, or write one outside the temp directory, and confirm it fails. A sandbox you haven't tested is a guess, not a safeguard.

• Fastest upgrade from plain Docker: add --runtime=runsc (gVisor) to the run command.
• --network none blocks outbound traffic entirely until you name an exception.
• No Docker: a disposable VM mounted to the project folder only.
• Test it: confirm a read or write outside the sandbox's scope actually fails.

Cloud sandboxing: when it's worth paying for someone else's isolation

Local isolation stops being enough once the code might be actively adversarial, once you're running many of these tasks at once, or once you'd rather not patch a hypervisor yourself. That's the case for hosted microVM providers: E2B, Daytona, and Modal are three of the better known ones, each running a task in its own isolated virtual machine rather than a shared one.

The trade-off is state. Several of these environments are ephemeral by design and discard everything when the session ends unless you export it first; others support longer-lived, resumable sessions. Check which kind you're using before you plan a workflow around keeping anything inside one.

We cover the specific providers that plug into OpenAI's Agents SDK, and how they compare, in a separate guide; this page is about the decision to go local or cloud at all, not which specific vendor to pick.

• Worth it when: code might be adversarial, you're running many tasks at once, or you don't want to operate the isolation layer.
• E2B, Daytona, and Modal each run a task in its own virtual machine.
• Check persistence per provider: ephemeral by default in some, resumable in others.

Four controls every sandbox needs, local or cloud

Writes: confine them to the project directory and a temp folder, nowhere else. A sandbox that lets code write anywhere protects nothing.

Reads: keep secrets and other projects out of view. If the sandbox can see your home folder, it can see your SSH keys and every other repository you own, whether or not the current task has any business touching them.

Network: decide on purpose whether the task can reach the internet at all, and if it can, which hosts. The most common way AI-written code causes real damage isn't a crash, it's a successful outbound request carrying data you didn't mean to send.

Secrets: never leave a credential in a file the sandboxed code can open. Inject it into the one command that needs it, at the moment it runs, from a keychain or a secrets manager, not from a plaintext file sitting next to the project.

• Writes: confined to the project and a temp folder.
• Reads: no secrets, no other projects in view.
• Network: decided on purpose, not left open by default.
• Secrets: injected at runtime, never sitting in a file.

What a sandbox never covers

A sandbox answers where code runs. It says nothing about whether the code is good. An AI agent can write a test that passes, a function with a subtle bug, or a dependency that doesn't exist, and a sandbox will happily contain all three without flagging any of them as a problem.

That's why a human review step before anything merges or deploys isn't optional, no matter how strong the isolation underneath it. Treat the sandbox as the thing that stops a mistake from reaching your real systems, and treat your own read of the diff as the thing that stops a mistake from reaching your codebase at all.

• A sandbox contains a mistake. It does not catch one.
• Review the diff yourself before anything merges, regardless of the isolation underneath.

Where Forkbench fits, for the local half

Forkbench is a desktop app for the Mac that runs your coding agent, whichever one you use, in a real terminal. It doesn't add a VM or a hardened container runtime of its own; what it adds is a folder lock, enforced by the macOS kernel sandbox, that keeps a Thread to the project directory you approved, and a Vault that keeps API keys in your Keychain so a command can use one by name instead of reading it from a file.

Know the limits before you rely on it. The folder lock is opt-in and does not restrict the network, so a locked agent can still send out whatever it's allowed to read. An unpinned Vault key can still be read by the program that was run with it. Forkbench governs what it holds and the folders you lock, not the whole machine, and it has no cloud sandbox of its own; for adversarial code at real scale, a hosted provider is still the right tool.

• Folder lock: opt-in, enforced by the macOS kernel sandbox, confined to the project directory.
• Vault: keys stay in the Keychain, used by name instead of being read from a file.
• Limits: the folder lock doesn't touch the network, and an unpinned key is still readable by the program using it.