Integrated Sandbox for AI Coding Agents

h5i (pronounced high-five) is an integrated sandbox for AI coding agents. It gives a coding agent a complete, disposable development environment inside a single security boundary: the agent, workspace, shell, dependencies, dev server and an isolated browser all run together inside it, while your host files and credentials stay outside. When the work is done h5i exports a reviewable patch and execution logs. One Rust binary, Apache 2.0, local-first, with no hosted sandbox and no SaaS account.

The lightweight tiers start in under 200 ms, which is what makes a box worth creating for an everyday agent task rather than only for a risky one. workspace and process are the fast path: they are a git worktree plus, at process, a Landlock and seccomp policy applied to a supervised process tree. container and microvm are deliberately slower, because one starts a container and the other boots a kernel. Pick the tier by the trust the run needs, not by the clock.

Yes. isolation = microvm boots a guest with its own kernel through microsandbox (msb), from the same OCI images the container tier uses. It is the one tier where the boundary is a hypervisor rather than a policy applied to a host process, so it is the rung to reach for when a shared kernel is not an acceptable assumption. It needs hardware virtualization on the host: /dev/kvm on Linux, Apple Silicon on macOS.

Yes. A browser box runs headless Chrome and a fresh profile inside the boundary, next to the dev server, so localhost means the same thing to both. The agent drives it from a CLI and reads an accessibility tree rather than raw HTML, clicking by handle. You can watch the same viewport over a loopback-only forward and take control at any point, which invalidates the references the agent held so it has to re-snapshot before acting. The page’s console errors and failed requests land in the execution log.

A container is one of the five tiers h5i can use, and on its own it is the weakest at the thing that matters most here. Its egress allowlist is an HTTP proxy, so it only binds tooling that respects proxy settings. h5i’s supervised tier puts the box in a private network namespace and enforces the allowlist with nftables rules pinned to resolved IPs, plus a seccomp gate on socket(): a program that ignores proxy settings still cannot reach an off-list address. On top of that you get the copy-in workspace, the credential broker, the browser, and the output gate, which a bare container does not give you.

No. The model API key stays on the host; a reverse proxy injects it into outbound requests, scoped per runtime, so a Claude box cannot reach an OpenAI credential. Any other service works the same way as a policy entry rather than a feature. The per-box copy of your agent’s HOME config has credential-shaped entries stripped at any depth, keeping only the runtime’s own token, which it cannot function without.

Three files, after you inspect them: a path-validated patch.diff, a report.md ordered by how much each section deserves your attention, and a receipt.json of observed execution. Together they answer what changed, what ran, and what was denied. Export is a step a human takes, so the agent has no direct write path back to your repository.

It cannot rewrite what is already recorded. The box’s only write window under its own directory is a staging spool; the receipt log and the stored payloads are siblings of that spool, outside every grant it has. The box stages a record, the host ingests it, and ordering and timestamps are the host’s. What an agent can still do is stage extra records or stop writing, and both are visible: a gap between host-observed exits and box-reported commands is itself a finding. We do not claim more than that.

No, and we will not imply otherwise. Containment stops the agent from touching your host. It does not stop it putting private code in a prompt to the model API. That is a separate control: a self-hosted model, or a profile with no model egress at all.

Neither, for the tiers most runs use. h5i uses Landlock, seccomp and unprivileged user namespaces, adding rootless Podman if you have it; only the microvm tier needs hardware virtualization. h5i box probe reports what your host can actually enforce, and runs a functional self-test rather than reading capability bits. An explicitly requested tier the host cannot satisfy fails closed: h5i never silently downgrades.

Below the microvm tier the kernel is shared, so this is good against a runaway agent and careless dependency code, and is not a claim against a targeted kernel exploit. Chrome runs with its own sandbox off, because h5i’s seccomp policy denies the namespace syscalls it needs. The box is the boundary, not Chrome. The viewport is a page, not a desktop. And it is Linux first: rootless Podman on Linux and WSL2, with macOS confining through Seatbelt. The manual keeps the full list.

Yes. Apache 2.0, written in Rust, local-first, with no lock-in, no hosted sandbox and no SaaS account required.

h5i began as a provenance system: prompt versioning, AI-aware blame, an audit scan, a multi-agent orchestra, a dashboard. Those are gone. The boundary was always the part worth having, and the product is being rebuilt around it. ROADMAP.md is the plan of record: what stays, what was cut, and what is still coming.