Evaluate agentOS (V8 isolate + WASM runtime) as the default sandbox execution engine

[vibegui]

Summary

Evaluate agentOS + secure-exec (Rivet's V8-isolate/WASM runtime) as the default execution substrate for Studio's sandbox engine, demoting our current Kubernetes-pod / desktop-daemon sandbox to a "heavy workload" fallback tier.

The core bet: we don't need a container or microVM per agent execution. agentOS runs untrusted/agent code as V8 isolates + WebAssembly inside a single shared Rust process, backed by a virtual kernel (VFS, process table, socket table, permission policy) that emulates POSIX syscalls instead of booting an OS. Isolation drops from "spin up a box" to "spin up an isolate": ~5–11 ms cold start, ~22–131 MB per instance, vs hundreds of ms and ~1 GB for E2B/Daytona-class sandboxes.

This directly unblocks self-hosted agentic CMS (the Stone "can't spawn sandbox environment" bug), improves the unit economics of running an agent per brand across our fleet, and aligns with our MCP-native / sandboxes-as-production direction.

The breakthrough (WASM + isolates)

Three things run inside one long-lived sidecar process, with no per-execution VM boot:

• JavaScript → V8 isolates. Each guest JS session gets its own isolate/context (same primitive as Cloudflare Workers). fs / net / child_process are polyfills that RPC into the Rust kernel — the filesystem, network, and subprocesses are all virtual and brokered by the sidecar.
• POSIX tools → WebAssembly. sh, grep, git, curl, vim, etc. are compiled to WASM and run in-process via wasmtime. Python runs the same way (Pyodide/WASM). Running git status in the VM touches no host binary and no container.
• Virtual kernel (secure-exec). A Rust kernel provides the VFS, process/socket tables, mounts (S3/R2, Google Drive, host dirs, overlays), and the permission policy + network allowlist. The security boundary is sidecar ↔ executor: V8/WASM isolate the guest within the process; the kernel brokers every syscall. Host-level jailing is a planned additional defense-in-depth layer (Workers-style).

Verified benchmarks (from the agentOS repo)

Metric	agentOS	Mainstream sandbox	Source
Cold start p50 (idle VM)	4.8 ms	440 ms (E2B)	README / benchmarks.md
Cold start p99	6.1 ms	3,150 ms (E2B)	same
VM create (session bench, real hw)	11.5 ms	—	scripts/benchmarks/baseline.json
Memory: full coding agent (Pi+MCP+fs)	~131 MB	~1,024 MB (Daytona)	README
Memory: simple shell command	~22 MB	~1,024 MB	README
Cost/sec, agent workload (Hetzner ARM)	~$0.0000011	17× cheaper	README

Honest caveat: the 4.8 ms figure is a minimal idle VM. Booting a full Pi agent session is ~1.5 s (a ~4× "VM tax" over bare Node's ~370 ms) — but that cost is the agent SDK, not the isolation. The isolation itself (VM create) is the ~11 ms line. Headline: isolation is nearly free; the cost is whatever the agent framework does on top.

How this compares to our sandbox today (mesh)

Our current sandbox is the opposite architecture: one K8s pod (via the agent-sandbox operator) or the user's desktop daemon per (user, project), running the agent harness (Claude Code, Codex via @decocms/harness) directly in a Node/Bun process with pod/namespace isolation.

	mesh sandbox (today)	agentOS/secure-exec
Isolation unit	K8s pod / desktop daemon per (user,project)	V8 isolate / WASM per execution, one process
Code isolation	Process/namespace only	V8 isolate + WASM + virtual-kernel syscall broker
Cold start	Pod scheduling / warm pools (seconds)	~5–11 ms
Density	1 pod ≈ 1 GB+	hundreds of isolates/host, ~22–131 MB each
Self-hosted	Needs K8s agent-sandbox operator (the Stone blocker)	Single sidecar binary — runs anywhere Node/Bun runs
Harnesses	Claude Code, Codex, decopilot	Pi, Claude Code, OpenCode, Codex (registry pkg) via ACP
Tool access	MCP endpoint + toolAllowlist	MCP tools + host "bindings" + permission policy

The mapping is clean: mesh's daemon /exec, /fs, /git, /tasks, /dispatch endpoints are almost exactly what secure-exec's kernel + ACP sessions provide natively — except isolation is per-call instead of per-pod. Our "code execution" Virtual-MCP strategy (load tools on demand in a sandbox, respect toolAllowlist) is agentOS's home turf.

Recommendations

Where it's a strong, near-drop-in replacement:

• Self-hosted isolation gap (Stone). Sharpest, most immediate win. Single sidecar, no GCP/K8s dependency → "create sandbox environment" works on a customer's self-hosted box. Unblocks agentic CMS for self-hosted.
• High-fan-out, short-lived tier. Overnight diagnostics, per-brand storefront.exe loops, tool dispatch, "code execution" Virtual MCPs. 8–47× memory reduction and ms cold starts change per-brand-agent economics (feeds the 60%→70% margin thesis).
• MCP-native + ACP. agentOS agents speak MCP for tools and ACP for sessions; host tools mount as bindings. Aligns with the "agents speak only MCP" commitment. The harnesses we already dispatch (Claude Code, Codex) exist as first-class agents/packages.
• Mounts as filesystem. S3/R2, Google Drive, host dirs, overlays mount as a VFS — maps to our org-fs/rclone story.

Where it is NOT a 1:1 replacement (keep the fallback tier):

• Heavy workloads: real browsers (Playwright), native compilation, big npm install with native addons, arbitrary Linux binaries. agentOS's own docs recommend pairing with a full sandbox (E2B/Daytona) here.
• Long-lived dev servers / preview URLs (mesh proxies a live npm run dev + preview iframe per project — prototype before assuming parity).
• Durable state: agentOS persists sessions/transcripts, but Durable-Object-backed agent memory stays where it is (the sidecar deliberately has no access to actor SQLite).

Proposed target architecture: agentOS becomes the default execution substrate; the container/pod sandbox demotes to the "heavy workload" fallback tier. Consistent with "sandboxes-as-production, compute is fungible, data is the moat" — strictly better compute for the common case, and it kills the self-hosted K8s dependency.

Plan to try it ASAP

It's already on npm — real experiment possible without touching mesh.

1. Fastest signal (½ day): npm install @rivet-dev/agentos @rivet-dev/agentos-sidecar in a scratch project. Create a VM, mount a real brand repo as a host-dir (or S3/R2) mount, run a Claude Code / Codex session over ACP against one of our MCP endpoints with a toolAllowlist. This mirrors exactly what mesh's /dispatch does. Confirm POSIX tools + git work in-VM.
2. The number that decides it: run our two real workloads side by side — (a) cold-start + memory of an agentOS VM vs spinning a mesh sandbox pod (density = margin story); (b) the heavy-workload cliff — a real npm install on a brand repo + a browser task, to find where we hit the "pair with a full sandbox" boundary.
3. The customer unblock demo: stand up the sidecar on a self-hosted-style box (no K8s) and show a sandbox environment spawning where mesh currently fails. That's the Stone unblock — the most concrete internal demo.

---

Prompt to start the coding thread

Build a proof-of-concept that evaluates agentOS as a replacement for our sandbox execution engine.

Setup: In a fresh scratch project, npm install @rivet-dev/agentos @rivet-dev/agentos-sidecar. Follow the quickstart at https://agentos-sdk.dev/docs/quickstart.

Build a minimal harness that:

1. Boots an agentOS sidecar + creates a VM.
2. Mounts a real brand/Studio repo into the VM (host-dir mount to start; try an S3/R2 mount next).
3. Runs a Claude Code (or Codex) session over ACP inside the VM, pointed at one of our MCP endpoints, constrained by a toolAllowlist — mirroring what mesh's daemon /dispatch does today.
4. Has the agent perform a representative storefront.exe-style task: read the repo, run grep/git, and draft a change. Verify the in-VM POSIX tools and git actually work.

Measure and report:

• Cold-start (VM create) and memory-per-instance for agentOS vs. spinning one mesh sandbox pod.
• The heavy-workload cliff: run a real npm install on a brand repo and a browser-driven task; document exactly where agentOS needs to hand off to a full sandbox (E2B/Daytona).

Stretch (the customer unblock): run the sidecar on a self-hosted-style box with no Kubernetes, and demonstrate a sandbox environment spawning where our current engine fails (the Stone self-hosted bug).

Deliverable: a short report with the numbers, a working code sample, and a recommendation on whether agentOS should become the default execution tier with the pod sandbox demoted to the heavy-workload fallback.

Research compiled from the agentOS (@rivet-dev/agentos) + secure-exec repos, the mesh sandbox implementation, and internal company/Studio context.

[pedrofrxncx]

Evaluation/research task (should Studio adopt agentOS as the sandbox execution engine), not a code fix — needs a decision before there's anything to scope. Smallest concrete next step if someone wants to de-risk this before committing: a standalone spike comparing cold-start time and memory per instance for the current sandbox path vs. agentOS on 1-2 real workloads, not a full migration.