The Problem

AI agents generate arbitrary code that must run isolated from the host and from each other. Docker's shared-kernel model carries container-escape risk, and full VMs are too slow and heavy for interactive agent loops. CubeSandbox targets that gap: hardware-level isolation via KVM with sub-60ms cold starts and under 5MB per-instance memory overhead, delivered through an E2B-compatible API so existing agent workloads can migrate without code changes.

What This Does

CubeSandbox is a collection of 11 self-contained projects forming a sandbox service. The core is CubeMaster (Go) — the control plane that schedules and manages sandbox lifecycles — and Cubelet (Go), the per-node worker. The hypervisor project (Rust) builds on RustVMM to provide the lightweight KVM-based runtime, and CubeAPI (Rust) exposes the HTTP API that is E2B SDK-compatible. CubeShim and agent handle in-guest runtime support; CubeNet and network-agent manage networking and egress controls.

The README claims cold starts under 60ms with memory overhead under 5MB per instance. The static analysis confirms the architecture: CubeMaster is the orchestration hub, Cubelet is the node agent, and the hypervisor project is substantial (382 files, 250 code files) but its internal structure was not mapped by the analysis.

How It Is Wired

Execution starts at CubeMaster/cmd/cubemaster/app/main.go, where Run is called from 79 places and reaches 405 functions. From there, control flows into CubeMaster/pkg/base/config/config.go (loaded by 41 files) and CubeMaster/pkg/base/node/node.go (used by 55 files) for cluster state. The CubeMaster/pkg/localcache/export.go owns database reads/writes for node registration and caching.

The most-connected file is CubeMaster/api/services/cubebox/v1/cubebox.pb.go — 538 functions, 64 types, called from 28 files. This is the generated gRPC/protobuf layer that defines the entire API contract. The cubebox_grpc.pb.go file is the client that calls Create, Destroy, List, and Update operations.

Filesystem effects are shallow: the shortest traced path from entry to an external call is main -> exportJSON -> os.WriteFile. The CubeMaster/pkg/templatecenter/template_image.go file handles both database and filesystem I/O for template image management. The call graph shows New called from 189 places and Close from 123 — these are the highest-blast-radius functions; changing their signatures breaks the most code.

How To Use It

The repo provides no single-command setup. Based on the structure:

# Clone and build the control plane
git clone https://github.com/moses-y/CubeSandbox
cd CubeSandbox/CubeMaster
make build  # Makefile present

# Build the API service
cd ../CubeAPI
cargo build --release  # Cargo.toml and Cargo.lock present

# Container deployment path exists
docker build -f CubeMaster/docker/Dockerfile -t cubesandbox .

The deploy/ directory (47 files) contains deployment manifests. Configuration lives in CubeMaster/pkg/base/config/config.go. The CubeAPI/examples/ directory has Python and Go client examples (create.py, exec_code.py, benchmark.go) that show the intended usage pattern against the E2B-compatible API. The README points to docs/guide/quickstart.md for setup instructions, but that file's contents were not extracted here.

Real-World Use

An agent harness running RL training on SWE-Bench tasks needs to execute untrusted model-generated code in isolation. With CubeSandbox, the harness calls the E2B-compatible API to spawn a sandbox, runs the code, captures the result, and destroys the sandbox — all in tens of milliseconds. The CubeAPI/examples/exec_code.py file demonstrates this exact flow: connect, create a sandbox, execute code, read output, close.

Code Health & Issues

Static analysis found 358 issues: 90 high, 260 medium, 8 low. The three distinct kinds:

  • High - Duplicated code blocks — 6,938 repeated 6-line blocks across 401 files, concentrated in CubeAPI/examples/ (Python clients). These should be extracted into shared helpers.
  • High - Deep nesting — 57 instances of indentation depth 10, in CubeAPI/src/logging/file.rs, CubeAPI/src/main.rs, and CubeMaster/cmd/cubemastercli/commands/cubebox/benchrun.go. Early returns would flatten these.
  • High - Oversized files — CubeMaster/api/services/cubebox/v1/cubebox.pb.go (3,935 lines) and CubeMaster/cmd/cubemastercli/commands/cubebox/template.go. The first is generated code (acceptable); the second is hand-written and should be split.

Security audit findings: the GitHub Actions use unpinned @v3/@v6 tags (docker/login-action@v3, etc.), continue-on-error is set on a correctness gate in build-check.yml, the Dockerfile uses ubuntu:25.04 without a digest, and no dependency vulnerability scan exists. The image also runs as root with no USER directive.

The Bottom Line

CubeSandbox is a serious, production-oriented sandbox infrastructure project, not a toy. The Go/Rust split is sensible, the E2B compatibility is a practical migration path, and the performance claims are plausible given the architecture. The main risks are operational: unpatched dependencies without Dependabot, unpinned CI actions, and a root-running container image. Teams already using E2B should evaluate this as a self-hosted alternative; teams without that constraint should weigh the operational maturity against simpler options.