Why does Capsem use a hypervisor instead of containers?
Containers are excellent for packaging and reproducibility, but they share the host kernel. Capsem runs each AI agent in its own Linux VM, giving the sandbox a separate kernel, filesystem, process tree, and network stack. That stronger boundary also enables true air-gapping, policy-controlled egress through Capsem's proxy, clean teardown of the whole machine state, snapshots and forks, and explicit host/guest control over vsock. Containers can still be useful inside a Capsem VM, but they are not strong enough to be the outer sandbox boundary.
Does Capsem work with Claude Code, Gemini CLI, and Codex?
Yes. Capsem supports any AI coding agent that runs in a terminal. Claude Code, Gemini CLI, and Codex are pre-installed in the VM and configured to work through the MITM proxy automatically.
How does the MITM proxy work?
All guest HTTPS traffic is redirected through an iptables rule to a local TCP relay, which bridges to the host via vsock. The host terminates TLS using per-domain minted certificates (signed by a static Capsem CA baked into the guest's trust store), inspects the HTTP request, applies policy, and forwards to the real upstream.
What platforms are supported?
Capsem supports macOS on Apple Silicon (M1 or later) through Apple's Virtualization.framework, and Debian/Ubuntu Linux hosts through KVM on x86_64 or arm64. The guest environment is always Linux.
Can I customize which domains are allowed?
Yes. Edit ~/.capsem/user.toml to define domain allow/block lists and per-domain HTTP rules (method + path matching). For enterprise deployments, /etc/capsem/corp.toml provides lockdown that individual users cannot override.
Is the VM truly air-gapped?
Yes. The guest has no real network interface. It uses a dummy NIC with capsem-dns-proxy and iptables rules that redirect all port 443 traffic through the MITM proxy. Direct IP access and non-443 ports are blocked entirely.