Skip to content

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
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
AgentENV1 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 eph2 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, 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, 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 — plus Superserve/Islo/Declaw/OpenComputer on configurable egress. That's the bar to beat.

EU data-residency is offered by two managed entries — Box (ascii.dev) (DE/FI/FR) and OmniRun (Hetzner/DE). Self-hostable tools (Mitos, Cleanroom, microsandbox, smolvm, …) can additionally be run in the EU by you. Still a minority across 37 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:

Process & namespace sandboxes

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

Filesystem & WebAssembly sandboxes

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. AgentENV sources: architecture, networking and persistence, environment injection, and license.

  2. 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

11 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages