agent-sandbox vs OpenSandbox
Kubernetes SIG Apps' Sandbox CRD and controller: stateful singleton pods with stable identity and persistent storage for agent runtimes and RL — templates, claims, warm pools; gVisor/Kata isolation. — versus — CNCF-landscape sandbox platform for AI agents: multi-language SDKs, unified API, CLI and MCP over Docker/Kubernetes runtimes — coding agents, GUI agents, evals and RL training.
Both give agents managed sandboxes on Kubernetes. OpenSandbox is a full platform (multi-language SDKs, CLI, MCP, Docker too); agent-sandbox is the minimal upstream CRD you compose yourself.
| agent-sandbox | OpenSandbox | |
|---|---|---|
| Stars | 4.0k | 15k |
| Forks | 530 | 1.4k |
| Language | Go | Python |
| License | Apache-2.0 | Apache-2.0 |
| Last activity | 3 days ago | 4 days ago |
| Topics | sandboxes, agents | sandboxes, agents, local |
| Curated connections | 5 | 6 |
agent-sandbox — the curator's take
Pick agent-sandbox when you already run Kubernetes and want agent sandboxes as a declarative, first-class resource: one long-lived pod per agent with a stable hostname, persistent volume, pause/resume and scheduled deletion, plus warm pools so claims start fast. It's upstream Kubernetes (SIG Apps), so it's the boring, vendor-neutral choice, with Go and Python SDKs and a router for reaching pods. The catch is in its own scope note: it orchestrates, it doesn't isolate. Security comes from the RuntimeClass you configure (gVisor, Kata); on the default runtime it's just a pod. No cluster? A microVM runtime like cubesandbox or a hosted sandbox SDK is far less machinery.
OpenSandbox — the curator's take
The platform play in agent sandboxing: one API over Docker and Kubernetes runtimes, SDKs in multiple languages, an MCP server, and OpenSSF/CNCF hygiene — built for the org that needs sandboxes as shared infrastructure across coding agents, GUI agents, eval harnesses and RL training, not a per-project tool. NOT the isolation ceiling: container runtimes trade the hard KVM boundary microVM sandboxes give you for operational familiarity — if untrusted code is the threat model, weigh a Firecracker-class runtime instead; if platform ergonomics on your existing K8s is the goal, this is the mature option.