Zerobox

What It Does

Zerobox is a lightweight CLI tool and TypeScript SDK that sandboxes arbitrary processes using OS-level isolation primitives — Seatbelt on macOS, Bubblewrap + Landlock + seccomp on Linux. It follows a deny-by-default model: file writes, network access, and environment variables are blocked unless explicitly permitted via CLI flags or SDK configuration. The core sandboxing code is derived from OpenAI Codex’s open-source sandbox crates, repackaged as a standalone tool.

Its most distinctive feature is credential injection via a local HTTP proxy. API keys are passed to the sandbox as placeholders; the proxy substitutes real values only when outbound requests target whitelisted hosts. This prevents sandboxed code from ever seeing or exfiltrating actual secrets.

Key Features

• Deny-by-default posture: All file writes, network access, and environment variables blocked unless explicitly allowed via --allow-write, --allow-net, --allow-env flags
• Credential injection proxy: Local HTTP proxy replaces placeholder secrets with real values only for whitelisted destination hosts, preventing secret exfiltration
• No Docker/VM dependency: Uses OS-native isolation primitives (Landlock/seccomp/Bubblewrap on Linux, Seatbelt on macOS) — single binary, no infrastructure
• TypeScript SDK: Deno-style API (import { Sandbox } from "zerobox") for programmatic sandbox creation with sandbox.sh(), sandbox.js(), sandbox.exec()
• Granular file access: Per-path read/write permissions (e.g., --allow-write=./output allows writes only to the output directory)
• Domain-based network filtering: Allow outbound traffic to specific domains only (e.g., --allow-net=api.openai.com)
• Clean environment inheritance: Only essential variables (PATH, HOME, USER, SHELL, TERM, LANG) passed through by default
• Cross-platform: macOS and Linux supported; Windows planned but not yet available
• Low overhead: Claims ~10ms startup overhead per invocation (not independently benchmarked)

Use Cases

• AI agent sandboxing: Wrapping AI coding agents (Claude Code, Codex CLI, etc.) to restrict file and network access during code generation, preventing accidental or malicious damage
• Untrusted script execution: Running third-party or AI-generated scripts with file write and network restrictions, without the overhead of spinning up containers
• CI/CD build isolation: Restricting build scripts to write only to designated output directories, preventing accidental modification of source files
• Credential-safe API calls: Running scripts that need API access without exposing actual keys to the script — useful for demos, shared environments, or untrusted plugins

Adoption Level Analysis

Small teams (<20 engineers): Good fit. The single-binary, zero-infrastructure design is ideal for individual developers or small teams who want guardrails around AI agents or untrusted scripts without operating Docker or VMs. The CLI is straightforward and the overhead is minimal. This is the primary audience.

Medium orgs (20-200 engineers): Limited fit. The tool lacks centralized policy management, audit logging, role-based permissions, or any multi-user governance features. Teams needing standardized sandbox policies across developers should look at Leash by StrongDM or container-based solutions with policy engines. Zerobox could be useful as a lightweight developer-local tool but does not replace organizational security infrastructure.

Enterprise (200+ engineers): Does not fit. No audit trail, no centralized management, no compliance reporting, single maintainer, no commercial support. The proxy-based credential injection lacks the enforcement guarantees required in regulated environments. Enterprise teams should evaluate E2B, Leash, or Northflank.

Alternatives

Evidence & Sources

• GitHub repository — 303 stars, 117 commits, MIT license, Rust + TypeScript
• Hacker News Show HN — 90 upvotes, 128 comments, cautiously positive reception
• OpenAI Codex sandboxing documentation — upstream implementation
• Deep dive on agent sandboxes — independent comparison by Pierce Freeman
• Better Stack comparison of sandbox runners (does not include Zerobox)

Notes & Caveats

• Single maintainer risk: Afshin Mehrabani is the sole contributor. The project has 117 commits and 303 stars as of April 2026. Bus factor is 1. Evaluate accordingly for anything beyond personal/hobby use.
• macOS network enforcement is advisory, not kernel-enforced: Network filtering on macOS depends on programs respecting HTTP_PROXY/HTTPS_PROXY environment variables. Programs that bypass proxies, use custom TLS, or make direct socket connections will circumvent network restrictions entirely. The README does not prominently document this limitation.
• Seatbelt is deprecated by Apple: The macOS sandbox mechanism (sandbox-exec) is officially deprecated. Apple continues to use it internally, so it is unlikely to disappear soon, but there is no guaranteed forward compatibility.
• Landlock kernel requirements: Linux network filtering requires kernel 6.4+. Filesystem sandboxing requires 5.13+. Older distributions (e.g., RHEL 8, Ubuntu 20.04) may not support all features.
• No security audit: The project has not undergone any independent security review. The README and HN discussion acknowledge the need for more thorough security documentation and testing.
• Proxy bypass risk: The credential injection pattern is clever but fundamentally relies on the sandboxed process using the proxy. Malicious code with direct network access (possible on macOS) can bypass it entirely. This is acknowledged by the author.
• No audit logging: Blocked operations are not logged or reported by default. There is no observability into what the sandbox prevented, limiting forensic utility.
• bwrap subprocess spawning: On Linux, Zerobox spawns Bubblewrap as a subprocess rather than making direct system calls, which was criticized in HN comments as adding unnecessary attack surface.