Capsem: An Open-Source VM Sandbox for Claude Code, Gemini CLI and Codex

Capsem is a new open-source tool that puts an AI coding agent in a disposable Linux virtual machine and watches everything it sends to the network. Its homepage promises "a Rust-powered hypervisor that sandboxes every AI coding agent in its own air-gapped Linux VM," with Claude Code, Gemini CLI and Codex preinstalled. It surfaced on Hacker News on October 15, 2026, where it drew a skeptical reception.

This post reads the README and the site side by side, because they disagree on several points. The short version: the design is sensible and matches where agent security is heading, but the project is early, and the claims about availability need checking before you rely on it.

Capsem at a glance

How does Capsem isolate an agent?

According to the site, each session boots a lightweight Linux VM using Apple's Virtualization.framework on macOS and KVM on Linux. The guest has a read-only root filesystem, a tmpfs workspace, no swap, no kernel modules, no debugfs, and no systemd, sshd or cron. State is ephemeral: every session starts fresh.

Capsem AI coding agent sandbox: a mechanical gripper working inside a sealed transparent dome

Networking is where the design gets interesting. The guest gets a dummy network interface and fake DNS. An iptables rule redirects HTTPS to a local relay, which bridges to the host over vsock, a socket channel between VM and host. The host runs a transparent man-in-the-middle proxy that mints a certificate per domain, signed by a Capsem certificate authority baked into the guest's trust store, inspects each request, and applies policy before forwarding.

Terminal I/O and MCP tool calls travel over separate vsock ports. That means the agent's tools, including built-in fetch_http, grep_http and http_headers, run as policy-checked calls rather than raw network access.

What can you control?

The site describes layers of configuration. Profiles own enforcement, detection, MCP, plugin and asset settings. Enforcement uses CEL rules, a small expression language also used in Google Cloud and Kubernetes policy. Detection rules can import and export Sigma, the common format for security detections. A corporate config at /etc/capsem/corp.toml, distributed through MDM, can lock policy and reporting so users cannot override it.

Every request and response body is logged to a per-session SQLite database for later analysis. For incident response, that is the most valuable piece: after an agent behaves strangely, you can see exactly which domains it called and what it sent.

Where the project's own pages disagree

This is the part most likely to matter before you install anything.

One Hacker News commenter, lasiotus, pointed out that the page says both native macOS and Linux packages exist and that Apple Silicon is required, and asked which is true. Another, lol8675309, criticized the leftover placeholders as a sign of low-effort, AI-generated content. A third, ducktective, asked how "air-gapped" is justified when traffic still leaves through a proxy. These are the commenters' views, not verified findings, but each question is fair, and the README itself notes that the release is still in qualification.

On the last point, our reading is that "air-gapped" describes the guest: it has no route of its own to the internet. The host proxy is a deliberate, policy-controlled hole. That is a gateway design, not a literal air gap, and the marketing wording overstates it.

Should you pipe the installer into your shell?

The homepage offers curl -fsSL https://capsem.org/install.sh | sh. For a security tool that is a poor look, and given the README says packages are not yet public, we did not run it and cannot vouch for what it installs. If you want to evaluate Capsem, build from the repository, read the code that handles the proxy and certificate authority, and run it on a machine without sensitive credentials first.

How Capsem compares with other sandboxes

Capsem sits among several approaches we have covered:

• Hosted sandboxes such as Cloudflare's Sandbox SDK run agents in the vendor's cloud. Capsem runs locally on your own machine.
• Container-style isolation shares a kernel with the host, so a kernel bug can break out. A VM puts a hypervisor boundary in the way, though the Vercel KVM zero-day is a reminder that hypervisors have bugs too.
• In-tool permission systems like the reviewer agent in Codex Auto-Review approve or block actions, but rely on the agent's own harness rather than an external boundary.
• Local control planes such as AgentPlane manage multiple agents, not their network egress.

The distinctive idea is forced egress inspection. Whatever the agent does, its traffic passes a policy point you control. Microsoft's CEO has urged similar thinking, assuming models may be compromised and building containment, as in our post on Nadella's emergency-brake framing.

What threat is this actually aimed at?

Coding agents run shell commands, install packages and read your files, so the realistic worries are three. A poisoned dependency or web page tells the agent to exfiltrate secrets. The agent itself makes a destructive mistake, such as deleting a directory or pushing to the wrong remote. Or a hijacked tool call reaches an internal service it should never touch. A VM with a read-only root and no real network route addresses the second and third directly: damage stays inside a disposable guest, and any outbound call has to pass a rule you wrote.

The first worry is only partly solved. Secrets in the guest, such as the model API key the agent needs, can still be sent to any allowed domain. That is why the per-domain method and path rules matter more than the VM wall: a rule that permits only POST /v1/messages on the model provider's host is far tighter than permitting the whole domain.

A practical evaluation checklist

If you decide to test Capsem, judge it on evidence rather than the homepage:

None of these results are in the project's documentation yet, so your own run is the only reliable answer.

Limits and risks

• It decrypts traffic. A MITM proxy sees API keys, prompts and code in plaintext. The tool is only as trustworthy as its code and its logs, which sit in SQLite on your disk. Protect them.
• It trusts a custom CA inside the guest. That is normal for this design but means a flaw in key handling would be serious.
• Prompt injection still works inside the allowed set. If policy allows a domain, an injected instruction can still send data there.
• Pre-release software. The README labels 0.6 as undergoing qualification. Treat features such as checkpoints and a VS Code extension, listed as coming soon, as roadmap, not product.
• Naming confusion. It is under the google GitHub organization but explicitly unofficial. Do not describe it as Google's sandbox.

What to do next

1. Read the README and its security policy before installing anything.
2. Start with an empty test repository and throwaway API keys.
3. Write a deny-by-default domain policy, then allow only your model provider and package registry.
4. Review the session logs after a run to see which requests the agent actually made.
5. Pair any sandbox with action-level controls. AgentBeam, from the explainx.ai team, stops AI agents before they take dangerous actions, which complements network isolation.

Bottom line

Capsem packs the right ideas into one tool: ephemeral VMs, forced egress inspection, MCP routing and policy as code. The unresolved questions are about maturity and honesty of the packaging, not the concept. Watch for the public release and independent reviews; until then, treat it as something to test, not to trust.

Related reading

• Cloudflare Sandbox SDK 1.0 for agents
• Vercel KVM zero-day and VM escape in agent sandboxes
• Codex Auto-Review guide
• AgentPlane local control plane
• Nadella on assuming models are compromised
• Claude Code mods guide

Details reflect the Capsem site and repository as of October 15, 2026 and may change before the public release.