A Lightweight Rootless Container Sandbox for Claude Code and Codex

What happened

I'll pull the source article and HN thread so the paragraphs stay grounded in named facts rather than invented details.Medium is blocking the fetch. I’ll pull the project docs and the author’s related write-up so the mechanics stay sourced.I have enough sourced detail from the official site and repo to write the post without inventing numbers. Drafting seven tight paragraphs now.Hideaki Takahashi published a Medium post under the Koukyosyumei account describing h5i as a lightweight rootless container sandbox for Claude Code and Codex. The write-up was submitted to Hacker News as item 49258898 and sat at 1 point with 0 comments. h5i, pronounced high-five, is an Apache 2.0 project from h5i-dev: one Rust binary, local-first, with no daemon and no SaaS account. The article’s claim is specific. The container tier runs Claude Code or Codex inside a rootless Podman container with every capability dropped, a read-only root filesystem, a pinned egress allowlist, and no daemon anywhere. h5i itself owns the disposable Git workspace, credentials, network policy, execution records, and final export. The container engine is currently Podman only.

A box is the isolation unit, not a per-command wrapper. Creating one copies a repository, a pull request, or an empty tree into a workspace; no host directory is mounted read-write into the agent’s reach. Claude Code or Codex, its child processes, package managers, builds, tests, and a dev server all run inside that same boundary. Isolation is a ladder. Workspace is only a separate Git worktree. Process adds a Landlock filesystem allowlist, a seccomp deny-list, namespaces, and rlimits. Supervised adds a private network namespace, an nftables egress allowlist pinned to resolved IPs, DNS pinned by a hosts file, and a seccomp-notify gate on socket. Container is rootless Podman with a portable image, a read-only rootfs, dropped capabilities, no-new-privileges, a private tmp tmpfs, user-namespace keep-id, and an HTTP and HTTPS CONNECT domain-allowlist proxy. Microvm boots a guest with its own kernel through microsandbox from the same OCI images. Credentials never enter the box. A runtime-scoped host proxy injects the model API key outside the boundary, so a Claude box cannot reach an OpenAI credential. The only way out is a human export: a path-validated patch.diff, a report.md of what ran and what was denied, and a receipt.json that records the policy digest actually enforced.

The technical detail

That layout matters because the usual way to make Claude Code or Codex useful is to skip permission prompts and let the agent inherit the laptop. Per-command approval just makes the human the security boundary, and a runaway install, a prompt-injected curl, or a dependency postinstall script still sees SSH keys, cloud tokens, sibling repositories, and the real browser profile. h5i is built for the opposite contract: give the agent full autonomy inside the box and keep the host outside it. Profiles pin one runtime. agent-claude and agent-codex each get only that agent’s HOME state and API egress. Lightweight OS-level isolation starts in under 200 ms, which is the number that decides whether you create a box for ordinary work or only for a branch you already distrust. The in-box browser is part of the same boundary, so testing a local server does not reopen your cookies and extensions.

Why it matters for builders

The market around this is crowded and mostly talking past each other. Claude Code and Codex already assemble Landlock, seccomp, and related kernel primitives; Takahashi’s earlier post, How Claude Code and Codex Sandbox Untrusted Code, compares those assemblies and then places h5i as a stronger environment where multiple agents can work and peer-review without colliding. Docker Sandboxes is the nearby productized answer, with agent templates and a microVM pitch that still assumes a Docker-shaped install. sandvault takes a different local cut on macOS by isolating into a separate non-admin user. h5i is narrower: Linux-first, rootless Podman on Linux and WSL2, Seatbelt on macOS, optional microsandbox when you have hardware virtualization. A bare container is one of five tiers and, on network control, the weaker one. Its allowlist is layer 7 and only binds tooling that respects a proxy. Supervised and microvm enforce at layer 3 and 4 and do not have that hole. The project’s own manual says the container tier buys portability, not tighter network control.

The practical move is to probe the host before you pick a story. h5i box probe reports which tiers the machine can actually enforce and runs a functional self-test rather than reading capability bits. An explicit tier the host cannot satisfy fails closed; h5i never silently downgrades. Use container when you want a portable image, dropped capabilities, and a read-only rootfs, and remember that security depends on the complete configuration, not on the word Podman. Use supervised when you care that a binary which ignores HTTP_PROXY still cannot reach an off-list address. Use microvm when a shared kernel is not an acceptable assumption, knowing it needs microsandbox, /dev/kvm or Apple Silicon, and a pre-pulled image. After a run, read the denied-egress section of report.md before applying the patch. Watch whether the container tier stays Podman-only, and whether Claude Code and Codex keep tightening their own sandboxes enough that an outer box becomes optional rather than required.

Market and competitive context

The limits are stated, and they are the parts to treat as load-bearing. Below microvm the kernel is shared, so this is a defense against a runaway agent and careless dependency code, not against a targeted kernel exploit. The container tier’s egress hole is real: a process that does not honor the CONNECT proxy can still leave. Chrome inside the box runs with its own sandbox off because h5i’s seccomp policy denies the namespace syscalls Chrome needs; the box is the boundary, not Chrome. Containment does not stop an agent from putting private source into a model prompt. That needs a self-hosted model or a profile with no model egress. Sharing a demo port is a separate inbound path, with a ticket as the whole access model and a Cloudflare tunnel option that is explicitly not end-to-end encrypted. The Hacker News thread has no comments, so there is no public adversarial review of the container flags yet.

What to watch next

h5i used to be a provenance system with prompt versioning, AI-aware blame, an audit scan, and a multi-agent orchestra. Those features were cut. The boundary was the part worth keeping, and the product was rebuilt around it. Related prior art sits close: Landlock and seccomp as used by the agents themselves, rootless Podman as the packaged form of those primitives, and microsandbox as the hypervisor rung. Open questions are whether the container tier will add another engine, whether layer-7 allowlisting will be brought up to the nftables standard, and whether enough people will actually create a box for everyday agent work now that the fast path is under 200 ms.