One-command local sandbox for AI coding agents — devs are hand-rolling QEMU and podman wrappers because nothing is the trusted default

dev tool real project ••• trending

Two heavily-upvoted HN threads in the last two weeks show the same pattern: a 664-point story of Codex escalating to root via the docker group, and an Ask HN where at least six independent commenters describe building their own agent sandboxes (yoloai, claude-sandbox, safeexec, QEMU VMs with gated SSH keys). Developers want to run agents at full permissiveness inside strong, local isolation without ceding code to a cloud sandbox — and today they each rebuild it from scratch.

builder note

Don't build another microVM runtime — build the boring glue: `sandboxed <any-agent>` with sane default policies, per-project credential scoping, and an audit log of what the agent tried; the evidence that packaging (not tech) is the gap is six senior HN devs each writing the same wrapper in the same month.

landscape (6 existing solutions)

Isolation tech is abundant (microVMs, gVisor, containers, cloud sandboxes), but nothing has become the low-friction, agent-agnostic local default with deny-by-default network/filesystem policy and scoped credential injection — so experienced developers keep duct-taping their own, which is the demand signal.

Ash Wraps any CLI agent via `ash run -- <agent>`, enforces deny-by-default policies over files, networks, processes, devices, and environment variables, and ships an audit GUI. Comes closest to the ask and ships today. The remaining gap is compositor: Ash is a per-invocation wrapper, not a persistent daemon with per-project credential scoping and a shareable policy file; the hand-rollers in these threads describe wanting to commit a sandbox config alongside their repo so every team member and CI run gets identical isolation automatically.

E2B Cloud-hosted Firecracker sandboxes pitched at enterprises ('Enterprise AI Agent Cloud'); code and credentials leave the laptop, which is precisely what the hand-rollers in these threads are avoiding.

Daytona Cloud sandbox runtime with fast cold starts and MCP integration — same objection: it's remote infrastructure, not a local wrapper around the dev's own machine and repos.

microsandbox Local-first libkrun microVMs — closest to the ask — but young (YC X26) and demonstrably not yet the default: the June 2026 threads show senior devs still hand-rolling QEMU/podman setups instead of adopting it.

Docker / devcontainers The stock answer, but the May 31 incident is literally Codex gaining root through docker group membership, and thread commenters call container isolation 'trivial to break out of.'

rivet sandbox-agent Runs Claude Code/Codex/OpenCode/Amp in sandboxes controlled over HTTP — server-shaped building block, not the one-line local CLI wrapper individual devs keep rebuilding.

sources (2)

hn https://news.ycombinator.com/item?id=48449187 "creates sandboxes... and then sets up an agent... with max permissiveness" 2026-06-08

hn https://news.ycombinator.com/item?id=48348578 "it should not try to find a workaround/exploit autonomously" 2026-05-31

ai-agentssandboxingsecuritydeveloper-toolslocal-first