Blog / subagents

Local Sandboxes for Running AI Agent Subagents Safely (2026)

Hotcell, microsandbox, Docker Sandboxes, agentbox and plain Docker compared for running many agent subagents in parallel on your own machine.

Local sandboxes for running AI agent subagents

The best open-source options for running AI agent subagents safely on your own machine are Hotcell and microsandbox. Both run each subagent in its own isolated environment on a laptop or server and keep real API keys out of it. Docker Sandboxes do the same and are free for local use, though Docker doesn't describe them as open source. agentbox suits one sandboxed agent per project, and plain Docker is a starting point that needs extra work to be safe.

This guide compares them on what subagents need. If you're after cluster-scale or self-hosted cloud sandboxes, see our open-source alternatives to cloud AI coding sandboxes. Last reviewed October 2026.

What subagents need from a sandbox

A single agent in a sandbox is one thing. A lead agent that hands work to five subagents at once needs more:

  • One sandbox per subagent, so a subagent that reads something hostile can't touch the others or your machine.
  • Fast creation and cleanup, because subagents are short-lived and created on demand.
  • Real keys kept out, because every subagent calls a model, and every copy of a real key is another chance to leak it.
  • Default-deny network, so a tricked subagent has nowhere to send data.
  • Limits per subagent: CPU, memory and, ideally, model spend, so one runaway can't starve or bankrupt the rest.
  • Runs on the machine you have: macOS, Linux or Windows, without a cluster.

At a glance

Licence Isolation Runs on Real keys kept out Per-sandbox spend cap
Hotcell Apache-2.0 Docker, Firecracker or Apple Virtualization microVMs macOS, Linux Yes, per-sandbox tokens via a host gateway Yes
microsandbox Apache-2.0 libkrun microVMs macOS (Apple Silicon), Linux with KVM, Windows Yes, secrets scoped to allowed hosts Not listed
Docker Sandboxes Not stated as open source; free for local use microVMs with a private Docker daemon macOS, Windows, Linux Yes, a host proxy injects credentials Not listed
agentbox MIT Docker container with an egress policy macOS, Linux (Windows via WSL2) Yes, secrets injected by a proxy No
Plain Docker Apache-2.0 (Moby) Container sharing the host kernel Anywhere Docker runs Only if you build it No

Hotcell

Hotcell is our sandbox runtime, built for running many agents on one machine. One daemon runs as many sandboxes as the hardware can hold, shows live CPU, memory and model cost for each, and refuses new ones when the machine is full instead of running out of memory. Each sandbox can be a Docker container, a Firecracker microVM on Linux or an Apple Virtualization microVM on macOS, chosen with --driver.

npm i -g hotcell
hotcell keys add openrouter
hotcell create -n 5 --name feat --branch auto --egress --egress-spend-cap 2 \
    --repo https://github.com/you/app
hotcell rm --all

That creates five sandboxes, each with the repo cloned on its own branch, a per-sandbox token instead of your key, and a $2 spending ceiling. A gateway on the host swaps each token for the real key, and tokens can be scoped further by model, rate and expiry, or revoked one at a time. On Linux, HOTCELL_EGRESS_ENFORCE=true makes egress default-deny at the host firewall; Apple Virtualization microVMs have no network device by default. Autopilot, our coding agent, uses Hotcell for its subagents: each runs read-only in its own sandbox.

If you just want coding agents that run in sandboxes like this, npm install -g directionallylocal sets up Hotcell and Autopilot for you; see the docs.

Limits: the key swap only works for credentials sent in HTTP headers, so database passwords and AWS SigV4 keys aren't covered, and egress enforcement is advisory with Docker Desktop on macOS. Windows isn't a listed platform.

microsandbox

microsandbox is an Apache-2.0 microVM sandbox built on libkrun, with a CLI (msb) and SDKs for several languages. Each sandbox gets its own kernel. You can allowlist hosts and declare secrets that never enter the VM, each tied to the host it may be sent to, for example an OpenAI key that only works for api.openai.com. It runs on Apple Silicon Macs, Linux with KVM and Windows with WHP, which makes it the widest choice for platforms. It's a good fit if you're building your own agent and want to embed sandboxes as a library. The project describes itself as beta, so expect breaking changes.

Docker Sandboxes

Docker Sandboxes (the sbx CLI) run each agent session in a microVM with its own Docker daemon and no path back to the host. A host-side proxy injects credentials into outbound requests, so the agent only sees a placeholder, and outbound traffic is deny-by-default. Docker's own docs warn that the default allowlist includes broad wildcards, so review it with sbx policy ls. It ships ready-made setups for Claude Code, Codex, Copilot, Cursor, Gemini, OpenCode and others.

Local use is free, including commercial use, and doesn't need a Docker Desktop licence, but it does need a Docker sign-in. Docker's docs don't describe it as open source, and we found no per-sandbox spend caps in them. It's the easiest option if you want to sandbox an off-the-shelf agent today.

agentbox

agentbox (MIT) runs a coding agent such as Claude Code, Codex or OpenCode in a Docker container that can only see your project, with outbound traffic filtered by a policy you edit (agentbox edit policy). Secrets are injected by a proxy rather than handed over as environment variables. It's designed around one sandboxed agent per project, not a pool of parallel subagents, and the project warns of breaking changes between releases.

Plain Docker

You can run each subagent with docker run, and many people start there. Out of the box, though, containers share the host kernel, keys passed with -e are readable inside, and the network is open. --network none blocks the network entirely, but then the subagent can't call its model either. To make plain Docker safe for subagents you end up building the proxy, the token layer and the egress rules yourself, which is what the tools above already do.

How to choose

If you need… Start with
Many parallel subagents with per-sandbox spend caps and keys on the host Hotcell
Sandboxes as a library inside your own agent, on Mac, Linux or Windows microsandbox
A quick, polished sandbox for an off-the-shelf agent Docker Sandboxes
One agent per project, configured with a CLI agentbox
A throwaway experiment with nothing sensitive in reach Plain Docker

FAQs

Do subagents need a sandbox if they're read-only?

Yes. Read-only stops them editing your code, but a read-only subagent can still run commands, read secrets and make network calls unless the sandbox prevents it. Isolation and key handling matter as much as write access.

Can I run these without a GPU or a cluster?

Yes. All of them run on a laptop or a single server. The model can be a hosted API or a local model; the sandbox doesn't care.

Are microVMs necessary, or are containers enough?

Containers share the host kernel, so a kernel exploit can escape them. microVMs give each sandbox its own kernel. For code you wrote, containers are usually fine; for agents reading untrusted repositories or the web, microVMs are the safer default. Hotcell lets you choose per sandbox.

How do I keep API keys away from subagents?

Keep the real key on the host and give each subagent a token that a proxy swaps for the key. Our guide on stopping coding agents from leaking API keys through subagents walks through it step by step.