Skip to content

About

Security-posture-first list of sandboxes for running AI coding agents' code, ranked by isolation, egress control and secrets handling

Topics

Resources

Code of conduct

Contributing

Stars

26 stars

Watchers

0 watching

Forks

Repository files navigation

Awesome AI Coding Sandboxes Awesome

A curated list of sandboxing and isolation solutions for running the code of autonomous AI coding agents (Claude Code, Codex, OpenHands, and friends) — organized by security posture first: how strong the isolation boundary is, and what the agent can still reach beyond it.

AI coding agents run arbitrary, model-generated commands. The hard part isn't speed — it's the security boundary (isolation) and what the agent can still do through it (network egress, secrets), plus durable workspace state for long tasks. This list ranks on those, not boot-time benchmarks.

Last updated: 2026-08-09 · Actively maintained — PRs welcome.

Contents

Comparison matrix

Isolation tier: microVM (own kernel) > gVisor (user-space kernel) > container (shared kernel) > process. Egress control = can outbound network be restricted — NOT whether it has network. deny-default / allowlist / configurable / full-by-default / none. Secrets = brokered (creds kept OUT via proxy) vs env-in (injected). Sorted by isolation tier, then egress strength. Abbrev.: eph = ephemeral · pers = persistent · Prop. = proprietary.

Project Isolation Egress control Secrets Self-host / Managed State License
Cleanroom Firecracker µVM deny-default brokered Self-host eph MIT
smolvm (smol-machines) libkrun µVM deny-default brokered Self-host both Apache
Leap0 Firecracker µVM deny-default (allowlist) brokered Both both Prop.
InstaVM Firecracker µVM deny-default (allowlist) brokered Both both Prop.
Mitos Firecracker µVM (Kubernetes) deny-default brokered Both pers Apache
ainclave Firecracker µVM deny-default brokered1 Managed ? Prop.
Sprites (Fly.io) Firecracker µVM allowlist env-in Managed pers Prop.
microsandbox libkrun µVM configurable (deny opt.) brokered Self-host (+cloud beta) pers Apache
Superserve Firecracker µVM configurable (allowlist) brokered Both both Apache
Islo Cloud Hypervisor µVM configurable (allow/deny) brokered Both (BYOC) both Prop.
Declaw Firecracker µVM configurable (allow/deny, L7) brokered Both (BYOC) both Prop.
OmniRun Firecracker µVM configurable (allow/deny) env-in Both eph Prop.
Vercel Sandbox Firecracker µVM configurable (deny-all) brokered Managed eph Prop.
BoxLite KVM/HVF µVM configurable (allowlist) brokered Self-host pers Apache
OpenComputer KVM full VM configurable (allowlist, L7) brokered Both pers Apache
Blaxel µVM configurable (preview) brokered Managed pers Prop.
Qbox Firecracker µVM configurable env-in Self-host eph unverified
Katakate (k7) Kata+FC µVM (K3s) configurable (allowlist) env-in Self-host eph Apache
AgentENV2 Firecracker µVM full-by-default (cfg) env-in Self-host both MIT
Freestyle Full VM/KVM configurable (on/off) unverified Managed both Prop.
Runloop VM + container full-by-default (cfg) brokered Managed pers Prop.
E2B Firecracker µVM full-by-default (cfg) env-in Both eph3 Apache
Northflank Kata+FC µVM full-by-default env-in Both (BYOC) pers Prop.
Arrakis Cloud Hypervisor µVM full-by-default env-in Self-host pers AGPL
SmolVM (Celesto AI) Firecracker+QEMU µVM full-by-default (allowlist) env-in Self-host both Apache
Morph µVM (VMM n/s) full-by-default env-in Both both Prop.
Tensorlake Firecracker+CH µVM full-by-default (allow/deny) env-in Both (BYOC) both Prop.
Box (ascii.dev) Linux VM full-by-default env-in Managed pers Prop.
Novita Firecracker µVM full-by-default env-in Managed both Prop.
Baponi Container (seccomp+cgroups, zero-cap) deny-default brokered Both both Prop.
OpenSandbox Container (opt. gVisor/Kata/FC) configurable (deny avail.) brokered Self-host eph Apache
Cloudflare Sandboxes VM-backed container configurable (deny avail.) brokered Managed both Prop.
Daytona Container (ded. kernel) configurable (tier-gated) brokered Both pers AGPL
AIO Sandbox Container (Docker) configurable (proxy) env-in Self-host eph Apache
Modal gVisor full-by-default (cfg) env-in Managed eph Prop.
Beam gVisor + runc full-by-default (cfg) env-in Both pers AGPL
Kubernetes Agent Sandbox gVisor/Kata (pluggable) none (delegated) env-in Self-host (Kubernetes) pers Apache
OpenHands Container (Docker) none env-in Both both MIT

What the data shows

Restricted-by-default egress is the minority. Deny-by-default: Cleanroom, smolvm (smol-machines), Leap0, InstaVM, Mitos, ainclave, Baponi; allowlist-default: Sprites. Sixteen offer configurable egress (opt-in), and the rest ship open outbound or delegate/none (Modal, Beam, Northflank, Arrakis, Box, Morph, Tensorlake, Novita, Kubernetes Agent Sandbox, OpenHands). Isolation is common; egress control is not.

Secrets brokering (creds kept out of the sandbox) is now a real cluster: Cleanroom, smolvm, Leap0, InstaVM, Mitos, ainclave, Superserve, Islo, Declaw, Vercel Sandbox, BoxLite, OpenComputer, Blaxel, microsandbox, Runloop, Baponi, OpenSandbox, Cloudflare, Daytona. Env-in: AgentENV, E2B, Modal, Northflank, Beam, Arrakis, SmolVM (Celesto), Qbox, Katakate, Sprites, Morph, Tensorlake, Box, Novita, AIO Sandbox, Kubernetes Agent Sandbox, OpenHands, OmniRun.

The strong-posture set (µVM/VM and restricted egress and brokered secrets) is small: Cleanroom, smolvm (smol-machines), Leap0, InstaVM, Mitos, ainclave — plus Superserve/Islo/Declaw/OpenComputer on configurable egress. That's the bar to beat.

EU data-residency is offered by three managed entries — Box (ascii.dev) (DE/FI/FR), OmniRun (Hetzner/DE) and ainclave (bare metal, EU). Self-hostable tools (Mitos, Cleanroom, microsandbox, smolvm, …) can additionally be run in the EU by you. Still a minority across 38 providers.

Control-plane reachable from inside (the "front desk" risk): Sprites documents an in-sandbox management API (reachable); Modal documents it is not. Others undocumented.

Control-plane authentication: AgentENV currently has no built-in API authorization. Its maintainers explicitly require deployment on a trusted network or behind an authorization proxy.

How these values were verified

Every cell traces back to the project's own documentation or source repository — not to blog posts, not to vendor comparisons, not to an earlier revision of this list. Where a project documents nothing, the cell says ? rather than a guess: an honest gap is more useful than a confident error. Contributors quote the supporting phrase in the pull request so a reviewer can check the claim without repeating the research, and the matrix is the single source for _data/sandboxes.json, which CI regenerates and diffs on every change — the structured data this page publishes cannot silently drift from the table above.

What this ranking does not measure

It reads documentation, not implementations. A deny-default cell means the project documents deny-by-default egress; it is not the result of a penetration test, and no escape research was done for this list. Cold-start latency, throughput, pricing, SDK ergonomics and language coverage are deliberately absent — they are covered well elsewhere, and they are not what fails when an agent gets prompt-injected.

A strong row also does not equal a safe deployment. Brokered secrets still require the broker to be configured; an allowlist is only as tight as its entries; a µVM with a mounted host directory has traded its boundary away. Read the matrix as a shortlist filter, then read the docs of the two or three candidates that survive it.

Why security-posture-first

Community consensus (HN, Reddit, the security literature) is blunt: containers are not a trust boundary for untrusted agent code, and isolation alone "solves the easiest problem" — the real risk is an agent with legitimate access exfiltrating data via network egress or leaked credentials (prompt injection). So we rank on the boundary and what crosses it, not on cold-start milliseconds (which matter only for ephemeral/high-concurrency workloads, not long-running coding agents).

Key nuance: almost every sandbox has outbound network — that's the problem, not a feature. The differentiator is whether egress can be default-denied and allowlisted, and whether secrets are brokered so the sandbox never holds them. A strong microVM with unrestricted network still lets a prompt-injected agent phone home with your code — isolation and egress control are orthogonal.

VMs & microVMs

Strongest isolation (own kernel per sandbox), built on Firecracker, libkrun, and Cloud Hypervisor. The verified µVM entries are in the comparison matrix above; the list below adds open-source projects not (yet) in the matrix.

Containers & gVisor

Shared-kernel isolation; faster, weaker boundary — built on gVisor and Kata Containers. Verified entries are in the matrix above; additional projects:

  • llm-sandbox - Python library that runs LLM-generated code on Docker, Podman or Kubernetes backends.
  • MCP Runner - Runs dockerized MCP servers as ephemeral, multi-tenant deployments on the gVisor runtime.
  • Kilntainers - MCP server that gives every agent an ephemeral Linux container for shell commands.
  • packnplay - Launches Claude Code, Codex or Gemini in per-worktree Docker containers; no introspection or access control.
  • yolobox - Container wrapper that grants the agent full sudo inside while keeping the host home directory out of reach.
  • vibebin - Self-hosted Incus/LXC platform for persistent agent sandboxes, with Caddy and direct SSH routing.
  • Leash - Wraps agents in containers and enforces Cedar policies on their activity; experimental container-free mode on macOS.
  • clampdown - Hardened container sandbox with an egress-filtering sidecar and an auth proxy that keeps API keys out of the agent container.
  • code-on-incus - Gives each agent its own Incus system container with root, systemd and Docker inside.
  • clawker - Self-hosted Docker sandboxes for coding agents, running behind an egress filter.

Process & namespace sandboxes

Syscall/filesystem/network restriction for individual processes, built on Bubblewrap, Landlock, and seccomp.

  • Anthropic Sandbox Runtime - Filesystem and network restrictions for arbitrary processes via Seatbelt on macOS and bubblewrap on Linux, plus proxy-based domain allowlisting.
  • NVIDIA OpenShell - Agent runtime that enforces declarative YAML policies on file access, exfiltration and network activity (alpha).
  • Greywall - Container-free, deny-by-default sandbox for filesystem, network and syscalls on Linux and macOS, with an allow-by-default watch mode.
  • Fence - Lightweight, container-free sandbox that runs commands under network and filesystem restrictions.
  • Landrun - Runs any Linux process in an unprivileged Landlock sandbox, firejail-style but kernel-native.
  • sandlock - Confines untrusted code with Landlock, seccomp-bpf and seccomp user notification; no root, no cgroups, copy-on-write working directory.
  • HiveBox - Namespaces, cgroups, seccomp and Landlock behind a CLI and REST API, one OpenCode agent per sandbox.
  • ClaudeCage - Packs Claude Code into a single portable bubblewrap sandbox scoped to one project directory.

Filesystem & WebAssembly sandboxes

  • AgentFS - Copy-on-write filesystem for agents stored in a single SQLite database; the CLI wraps an existing program in a sandboxed session.
  • LocalSandbox - Python SDK combining just-bash, AgentFS and Pyodide into a persistent WebAssembly-backed bash/python environment (beta, unaudited).
  • Wassette - Security-oriented runtime that serves WebAssembly Components as MCP tools.
  • Eryx - Runs untrusted CPython on Wasmtime with memory and CPU limits and no filesystem or network access by default.
  • Capsule - Runtime that executes agent tasks as untrusted code in isolated WebAssembly environments.
  • AgentVM - Node.js library running an Alpine Linux VM compiled to WebAssembly (container2wasm) in a worker thread.
  • amla-sandbox - WebAssembly sandbox for agent code with capability enforcement, a virtual filesystem and no network.

Isolation building blocks

Project Type License
Firecracker microVM (KVM) Apache-2.0
Cloud Hypervisor microVM (KVM) Apache-2.0
Kata Containers microVM (OCI/CRI) Apache-2.0
gVisor user-space kernel Apache-2.0
libkrun microVM library Apache-2.0
Flintlock microVM lifecycle mgmt MPL-2.0
forkd fork-from-warm µVM engine (Firecracker) Apache-2.0
Bubblewrap process sandbox LGPL-2.0

Adjacent

Related but not untrusted-code sandboxes for coding agents:

  • Ona - Formerly Gitpod; container-based CDE + agent orchestration. Acquired by OpenAI (announced June 2026, deal pending); folding into Codex.
  • Coder - Self-hosted CDE; isolation delegated to the provisioned backend. AGPL-3.0 (+ enterprise).
  • CodeSandbox SDK - microVM CDE (now part of Together AI); primarily a dev environment.
  • GitHub Codespaces - Cloud dev environments; see also Replit.
  • Steel.dev - Sandboxed browser sessions (not general code exec).
  • Clusy - Agent-native notebook for ML/data science; managed-only, runs agent-written cells on cloud CPU/GPU "managed cloud sandboxes". Isolation mechanism, tenant boundary and egress controls undocumented; workspace separation stated as logical only.
  • ComputeSDK - Provider-agnostic router/SDK across sandbox backends (no own isolation); see also VibeKit.
  • agentbox (madarco) - Self-hosted CLI running coding agents in parallel (Docker+FUSE / cloud VM); dev-workflow tooling on off-the-shelf isolation. MIT.
  • Giant Swarm Agent Platform - Kubernetes-based agent governance/orchestration control plane (MCP); ships no dedicated untrusted-code sandbox.
  • Fireactions - GitHub-Actions runner orchestrator on Firecracker µVMs; no agent/sandbox API. Apache-2.0.

Contributing

PRs welcome — and actually reviewed (as time allows; no bot auto-closing your PR). See CONTRIBUTING.md and the Code of Conduct. Maintained by @fhiltscher (LinkedIn).

  • One project per PR. Every matrix cell needs a source link (official docs/repo). Don't know a value? Use ? — never guess.
  • Entries must run agent-generated code with a real isolation boundary; no dead projects, no marketing-only pages. License is not a criterion.
  • Spotted stale or wrong data? Open an issue or PR — accuracy is the whole point.

Released under CC0-1.0 — public domain.

Footnotes

  1. ainclave's own docs describe a placeholder env var, live-substituted on the outbound request by a proxy — but that proxy runs inside the same guest as the agent process, and ainclave itself calls cross-process leakage to the agent "untested." ↩

  2. AgentENV sources: architecture, networking and persistence, environment injection, and license. ↩

  3. E2B is ephemeral but supports pause/resume. ↩

About

Security-posture-first list of sandboxes for running AI coding agents' code, ranked by isolation, egress control and secrets handling

Topics

Resources

Code of conduct

Contributing

Stars

26 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages