OpenSandbox's CLI passed our installation, build and test steps. Running an agent workload still requires a reachable server and a runtime. For a platform team, the next decision is whether to operate those components and verify their behavior on the intended backend.
What happened when we ran it
Our sandbox installed the Python project in ./cli/ in 30 seconds, built it in 2 seconds and completed the test step successfully in 81 seconds. The run used commit 392aab3 on November 9, 2026. The record supplies no passing-test count.
We recorded 54 dependencies and 53 MB on disk for this installation. The whole checkout contained 3,223 files, approximately 669,961 source lines and 99.2 MB. These measurements do not include the requirements of workload images or a deployed Kubernetes service.
Pip-audit reported zero known vulnerabilities among 52 scanned packages; two reported packages were skipped. That result does not certify other components, workload images or the isolation boundary.
The configured environment had 3 CPUs and 8 GB RAM, with image label ghcr.io/astral-sh/uv:python3.12-bookworm. The label does not establish actual runtime or operating-system versions. The scan recorded 22 CI workflow files and a tests directory, with no Dockerfile detected. That scan result does not contradict the project's documented distribution of published container images.
The run establishes CLI installation, build and test outcomes. It does not establish sandbox creation, browser operation, isolation strength, cluster reliability or startup latency.
The server is a separate setup task
The project README describes Docker for local execution and Kubernetes deployment through a unified sandbox API. Its local quick start requires Docker and Python 3.10 or newer, initializes server configuration and starts the server.
The CLI guide then requires a reachable server and shows configuration for the connection domain, protocol and API key. Installing the command-line package alone does not reproduce that service setup.
There is also a checkout-specific detail: the guide says development commands run from cli/ resolve against the checked-out Python SDK through a local uv source override. Our result therefore does not establish compatibility across separately published client and server versions.
Reproduce the documented workflow on your backend
The CLI guide supplies an acceptance sequence: create a sandbox, inspect it, check its health, run a command, write and read a file, then kill the sandbox. These are documentation-derived steps that this lab record did not execute. Reproduce them against your server and retain the diagnostics before relying on the service.
Two documented behaviors matter for automation. First, template management requires a Kubernetes-backed runtime. A Docker-only trial cannot validate that workflow. Second, pause is asynchronous. Poll the sandbox until the transition finishes rather than treating request acceptance as the completed state.
The guide also distinguishes shell commands from literal arguments. By default, the payload after -- is joined into a shell command string. The --argv option sends a literal argument list when the sandbox image's execution daemon supports argv requests. Check that support before depending on literal handling of spaces, quotes or shell syntax. This review has not executed either command mode.
Check signing evidence for the exact artifact
The supplied release metadata identifies release-1.2.0, published October 27, 2026. Our measured checkout is commit 392aab3; the CLI run is not a test of an installed release-1.2.0 artifact.
The release verification guide specifically names release-1.2.0 among the examined releases with reported missing signatures and provenance. It says the current umbrella release process lacks the signing coverage of the older per-component workflows.
For umbrella images, the guide directs users to the versioned release BOM for a digest. Matching that digest checks artifact identity, not who built it. If your deployment policy requires a signature or provenance, verify the exact artifact and resolve any missing evidence before adoption. We did not independently verify release signatures.
E2B and gVisor serve different requirements
E2B's README documents cloud sandboxes controlled through JavaScript or Python SDKs. Its quick start asks for an E2B API key, and it also includes a self-hosting route. Consider the documented cloud workflow when that operating model suits your application. This review does not compare costs, deployment effort or behavior under load.
gVisor's README describes an application kernel and the runsc runtime, which integrates with Docker and Kubernetes. Consider it when an existing container platform needs an isolation layer. Assess the surrounding lifecycle and agent interface separately. Neither alternative is a measured winner in this review.
How the ratings work
The documentation rubric assigns 1/5 when usable task instructions are absent, 2/5 when essential steps are missing, 3/5 when instructions are actionable but material verification gaps remain, 4/5 when the principal workflow has been reproduced, and 5/5 when the relevant deployment routes have been independently checked.
Documentation receives 3/5. The supplied guides explain connection setup, health checks, cleanup, template restrictions and artifact-verification limits. Our record does not reproduce their live workflow. Setup ease, community support and operational maturity remain unassessed because the CLI checks do not establish those outcomes.
The next useful result is a recorded create, health, command, file and cleanup sequence on your chosen backend, with diagnostics for any failure.