A Sandbox is one durable pod, not a miniature cluster
Agent Sandbox defines a Kubernetes Sandbox resource for a single stateful workload with a stable hostname, network identity, and optional persistent storage. The controller creates and replaces the underlying pod while preserving the higher-level identity. Scheduled deletion, pause, and resume fit coding agents, notebook sessions, small single-instance services, and evaluation workers better than a Deployment designed around interchangeable replicas.
Extensions add SandboxTemplate, SandboxClaim, and SandboxWarmPool. A template describes reusable configuration, a warm pool keeps sandboxes ready, and a claim adopts one for a caller. This is the appealing part for reinforcement-learning or evaluation systems: allocation becomes a Kubernetes API operation rather than bespoke code around pods, services, and volumes. The README still describes one container per Sandbox, so multi-container workspace assumptions need testing.
Isolation comes from RuntimeClass, not the controller
The project calls itself a sandbox orchestrator. It configures pods to use a secure runtime, while gVisor, Kata Containers, or another implementation supplies kernel and network isolation. That boundary matters when the payload is untrusted model-generated code. Installing the CRD alone does not turn the default container runtime into a stronger security boundary.
A production review must therefore cover the selected RuntimeClass, node pools, storage class, network policy, image admission, pod security, and what credentials enter the sandbox. Our checkout had a Dockerfile and 6 CI workflow files, but those repository signals cannot answer whether a cluster blocks host access or lateral traffic. The project's threat model is the correct starting document; the one-command manifest is only the controller install.
What happened when we ran it
Our sandbox at commit 2fd412d installed 195 Go packages in 86 seconds and completed the build in 136 seconds. The checkout held 1,346 files, about 138,751 source lines, and 13.5 MB before dependencies. Those numbers are reasonable for a Kubernetes controller with core resources, extensions, Go and Python clients, a router, examples, Helm work, and generated APIs.
Tests ran for 53 seconds and exited with failure. The supplied summary counted 26 passing and 2 failing groups out of 28. In the log tail, TestWarmPoolRolloutMetadataUpdate, TestWarmPoolSandboxWatcher, and TestWarmPoolPodNameAnnotationBeforeReady each reported that /work/repo/bin/KUBECONFIG did not exist. The extension end-to-end package then failed. The log does not show why that file was absent, so we would not label this a controller defect or wave it away as harmless.
Installation is short; cluster preparation is the work
The recommended manifest combines the core controller and extensions for GitOps tools. Operators pin a release and apply sandbox-with-extensions.yaml; separate core and extension manifests are also available. Verification checks the Sandbox CRD and controller deployment. Go consumers install the root module's client package, while a separate Python client provides higher-level creation and management calls.
Before any of that is useful, the cluster needs nodes that support the chosen sandbox runtime, a RuntimeClass, suitable storage, registry access, and RBAC. Warm pools also consume capacity before claims arrive, so teams need quotas and reclamation rules. Our 3-CPU, 8 GB Debian container built the source but did not stand up Kubernetes, create a Sandbox, attach a volume, or measure allocation latency. The project makes no lab result for those steps available through our run.
Warm pools trade idle capacity for faster claims
A claim can adopt a prepared Sandbox from a pool instead of waiting for every resource to start from zero. That model suits test runners and agents where startup delay interrupts an interactive request. Templates also give platform teams one place to enforce images and resource settings across many consumers. The API shape is cleaner than handing every application permission to manufacture pods directly.
Capacity planning does not disappear. Pool size, image pull behavior, persistent-volume binding, failed Sandbox replacement, and abandoned claims all affect cost and availability. The roadmap discusses deeper hibernation, automatic resume, richer identity, and memory sharing as desired characteristics or exploration areas. Treat those words as direction, not delivered behavior. Buy against the current CRDs and release artifacts.
Uninstall and API changes need operator discipline
The README gives an unusually blunt uninstall warning: deleting the CRDs cascade-deletes their custom resources across namespaces. An operator should inventory Sandboxes, claims, pools, and templates before removing manifests. Backing storage behavior then depends on the cluster's reclaim policies, another reason to rehearse removal outside production.
GitHub showed 206 combined issues and pull requests and a last push on August 26, 2026. Release v0.5.6 arrived on August 20. Active work included Helm chart checks, router changes, suspend and resume design, Python client retry behavior, and runtime-aware CI. This is healthy development under Kubernetes SIG Apps, though the queue and recent release cadence signal that adopters should pin manifests and read upgrade notes.
Kubernetes teams get the clearest payoff
Agent Sandbox is convincing when a platform already speaks CRDs, controllers, RuntimeClass, and persistent volumes. It gives that team a named resource for a workload that otherwise becomes a pile of one-replica primitives, plus claim and warm-pool behavior aimed at agent and evaluation systems. Apache-2.0 licensing and both Go and Python clients reduce integration friction.
The failed 53-second test run keeps this from an unconditional recommendation. Reproduce the suite with the repository's intended cluster prerequisites, then test isolation and cleanup with the runtime you will deploy. If Kubernetes is absent from the current stack, E2B or Daytona offers a shorter conceptual path. If VM boundaries are mandatory, KubeVirt is the more direct comparison.