Capsem is a new open-source project that runs AI coding agents (Claude Code, Codex, Gemini CLI) inside ephemeral, air-gapped Linux VMs and forces their HTTPS traffic through an inspecting proxy. It is a real approach to the question "what can my agent reach?", but its public pages disagree on how finished it is. This post summarizes what Capsem's site and GitHub repository say, flags the gaps, and explains where it fits next to Beam.
TL;DR
| Question | Answer |
|---|---|
| What does it do? | Boots each agent session in a short-lived Linux VM, with network traffic proxied and logged on the host. |
| Is it ready? | Unclear. The site shows an install script and packages; the README says 0.7 is a pre-release with install and packages withheld until a public release. |
| Does data leave my machine? | The site describes a local proxy and per-session SQLite logs. The agent's own traffic to its model provider still goes out, through the proxy. |
| Does it replace Beam? | No. Different layer: isolation versus observation and policy on the host. |
How Capsem sandboxes an agent
Per the site, each session works like this:
- A lightweight VM boots with a read-only root filesystem and a tmpfs workspace, with no swap, kernel modules, systemd, sshd or cron.
- The guest gets a dummy network interface and fake DNS, so it cannot reach the network directly.
- All HTTPS goes to a proxy on the host that terminates TLS, inspects each request, applies policy and forwards it upstream.
- Full request and response bodies are written to a per-session SQLite database.
- Policy is per profile, and an optional
/etc/capsem/corp.tomlcan lock settings so users cannot override them.
It also ships an MCP endpoint with built-in tools (fetch_http, grep_http, http_headers), detection rules with Sigma import and export, and claims boot to prompt in under 10 seconds. Supported hosts are macOS 14+ on Apple Silicon and, per the README, Ubuntu 24.04+ or Debian 13+ with KVM.
Update (October 20, 2026): the pages have moved since the first read
Five days after this post, the sources differ from what we first read. The GitHub README now describes Capsem 0.7 as a pre-release "undergoing release qualification", and still says installation instructions, downloadable packages and detailed documentation are "intentionally unavailable until the public release". The project site, meanwhile, offers a macOS Apple Silicon .pkg, Linux x86_64 and ARM64 .deb packages, and a curl -fsSL https://capsem.org/install.sh | sh line, and its download links point at a v0.6.6 release on GitHub. A full documentation site is now live too. The README's platform table lists macOS 14 or later on Apple Silicon, and Ubuntu 24.04 or later and Debian 13 or later on KVM-capable x86_64 or arm64, and the repository's LICENSE file is Apache-2.0. So the platform and license ambiguity from the first read is smaller, but the release-status question is not settled: the README and the site still describe different states. We have not installed it.
The new documentation also fills in several details that the first read lacked. They are covered in the sections below.
How the host side is built
The system architecture page says Capsem "runs as a service" in the way Docker does. You control it from a CLI, a terminal UI, a graphical Capsem UI, or a Python, TypeScript or Rust SDK. Each of those goes through an authenticated gateway to a shared service, and the service starts per-VM workers.
Each VM gets its own security engine process (capsem-proxy), its own log writer (capsem-ledger) and its own MCP workers. Inside the VM, the agent runs in an OCI container created by runc, with user, PID, mount, IPC, UTS and network namespaces, noNewPrivileges=true, and CPU, memory and PID limits. According to the security architecture page, the container's seccomp profile denies vsock sockets, so the agent cannot talk to host channels directly, and it holds no CAP_SYS_ADMIN.
The host processes are confined as well. On Linux, workers install Landlock filesystem, network and signal restrictions plus seccomp syscall filters. On macOS they use Seatbelt. The security engine, for example, is described as having no filesystem path grants and as unable to open credential storage or the session database. Stopping or replacing a VM retires its worker generation and revokes its capabilities.
The page is plain about what is still trusted: "The host kernel, hypervisor, and service remain trusted." It also says the ledger detects changes to checkpointed records but "cannot prove that a compromised producer reported an observation truthfully". That is a useful limit to keep in mind when you read the audit trail.
How a request is decided
The security engine page describes the path a request takes. The steps, as documented:
- Guest helpers send HTTP, HTTPS, DNS and MCP traffic over vsock to the engine.
- The engine terminates TLS with a certificate generated for the requested hostname and signed by a Capsem certificate authority that the VM trusts. It then opens a separate TLS session to the real upstream and validates that certificate against the hostname.
- Rules written as CEL conditions are evaluated against typed facts such as the host, the model provider or the MCP tool name. The site shows examples like
http.host == "untrusted.example"andmcp.tool_call.name == "delete_file". Defaults, user settings and corporate rules compile into one rule set, and corporate constraints take precedence. - Postprocess plugins can only tighten a decision, in the order allow, ask, block. An
askdoes not mean allow: the operation waits for approval. - If the request is allowed, the engine restores real credentials into the upstream request. The VM only holds references; the page says credential material "stays outside the VM".
- A sanitized event, with observed secrets replaced by references or redacted values, goes to the log writer. If a required audit record is refused, the operation is refused too.
Two limits appear in the same page. Network connection and probe events require an explicit allow rule. And a client that pins the upstream certificate or rejects the Capsem CA cannot use the intercepted connection, so some tools will break unless policy lets them through another way. Private networks and published ports do not pass through HTTP inspection at all.
Detections are separate from rules. Capsem accepts Sigma-format YAML detection files, and its site gives an example that flags a read of passwords.txt. Rules decide whether something proceeds; detections record that something matched.
What is unclear
Treat these as open questions, not defects we have confirmed:
- Release status. When we first read it, the README said Capsem 0.6 was undergoing release qualification, with installation and packages "intentionally unavailable until the public release, planned for Summer 2026". It now says 0.7. The site, in October, shows a
curl | shinstaller and package downloads. - Who is behind it. The repository sits under a
googleGitHub organization, yet its README states it is not an official Google project and is unsupported by Google. - Platform and license details. The site lists Linux support in one place and "coming soon" in another, and the license reads differently on the site (MIT) and the repo page (Apache-2.0).
- "Air-gapped." One Hacker News commenter (ducktective) asked how it is air-gapped; from the site, the answer appears to be no direct network, with a policy-controlled proxy as the only path. Another commenter (lasiotus) pointed to the conflicting platform statements, and a third (lol8675309) criticized placeholder screenshots on the page.
- Proxy trust. A TLS-terminating proxy sees plaintext including tokens, so the logs it writes are sensitive. The documentation says the engine redacts observed secrets from stored events and holds the real credentials outside the VM; that is a design claim from the project, and we have not verified it. Check where the logs live and who can read them.
- Benchmarks. The site quotes a 1.2 second environment launch, a 60 millisecond duplicate and roughly 3,000 requests per second through the proxy. Its own footnote says these are recorded from macOS ARM64 runs in May and June 2026, rounded, and "do not measure agent readiness or external network speed". Read them as the project's measurements, not as a promise for your hardware.
What developers are saying
The Hacker News thread is small, at 8 points when we read it, and it is mostly questions. Three comments are worth recording as the commenters' own reports:
- ducktective asked, in effect, how a tool can be called "air-gapped" when the agent still reaches a model provider. The documentation's answer is that the VM has no host-network interface and traffic reaches the outside only through the policy-controlled proxy. That is network mediation, not the usual meaning of air-gap.
- lasiotus reported that the site's install line and its platform statements seemed to contradict each other, and that the home page had placeholder screenshots. We did not find that platform text on the home page when we fetched it on October 20.
- lol8675309 said the placeholder screenshots reduced their confidence in the page.
None of the three reproduced or tested the sandbox. The thread says something about how the project presented itself, not about how well the isolation holds.
What this means if you run AI coding agents
- Isolation and observation answer different questions. A VM limits what a hijacked agent can reach. It does not tell you whether the agent was manipulated or what it tried. See our monitor versus block comparison.
- Sandboxes fail too. Read the Perplexity sandbox escape red-team write-up before treating any boundary as absolute.
- Anything you mount or forward is in scope. Credentials, SSH agents and repos you expose inside the VM are what an attacker gets.
- Decide what you will not mount. Capsem's design keeps provider keys outside the VM by substituting them at the proxy. Anything you copy into the workspace or forward yourself, such as an SSH agent or a
.envfile, is not covered by that. - Expect friction with pinned clients. Because the proxy re-signs TLS, tools that pin certificates will fail until a rule or exception handles them.
- Before adopting, verify: the release you are installing (the README and the site disagreed when we looked), where proxy logs go, which hosts are allowed by default, and whether your team can live with a TLS-terminating proxy.
What Beam can and cannot do here
Beam is not a sandbox. It runs on your machine, watches what Claude Code, Codex and similar agents do, flags risky actions such as credential exposure and destructive commands, and scans skills and MCP configs with 11 heuristics plus a version-pin check, keeping data on-device with redaction before storage (how it works). It can deny through Claude Code and Codex PreToolUse hooks; that is hook-based, not a kernel boundary, and heuristic. It fails open if cached policy is missing. For stopping dangerous commands in Claude Code, Beam's hook is the relevant piece; a VM like Capsem would be an additional, separate layer. We have not tested Capsem alongside Beam, so we make no claim about running them together. For the broader picture see what agent harnesses are.
Frequently asked questions
What is Capsem?
An open-source Rust hypervisor that runs each coding agent in an ephemeral Linux VM with a read-only root and no direct network, inspecting HTTPS through a host proxy.
Which agents does Capsem support?
Claude Code, Gemini CLI and Codex are listed as pre-installed, plus an MCP endpoint and custom MCP servers.
Is Capsem ready to install?
Its pages conflict: a site install script and package downloads versus a README calling 0.7 a pre-release. Check current release status first.
Is Capsem a replacement for Beam?
No. Capsem isolates where an agent runs; Beam observes and flags what agents do on your machine and can deny through hooks.
Does a VM sandbox stop prompt injection?
It limits the blast radius but does not stop an agent from being manipulated or from misusing what you expose inside the VM.
Related reading
- Introducing Beam: local-first AI agent security
- AI agent security: monitor vs block
- Perplexity sandbox escape red-team
- Why Beam is open source
- Google's Agent Compute Engine: a microVM per agent, no credentials inside
- Sources: Capsem, Capsem documentation, google/capsem on GitHub
This post reflects Capsem's public pages and Beam's documented features as of October 20, 2026. Capsem is moving quickly and its pages were inconsistent when we read them; verify details against the current release.