This looks really good - the CLI interface design is solid, and I especially like the secrets / network proxy pattern - but the thing it needs most is <i>copiously detailed</i> documentation about exactly how the sandbox mechanism works - and how it was tested.<p>There are dozens of projects like this emerging right now. They all share the same challenge: establishing credibility.<p>I'm loathe to spend time evaluating them unless I've seen robust evidence that the architecture is well thought through and the tool has been extensively tested already.<p>My ideal sandbox is one that's been used by hundreds of people in a high-stakes environment already. That's a tall order, but if I'm going to spend time evaluating one the next best thing is documentation that teaches me something about sandboxing and demonstrates to me how competent and thorough the process of building this one has been.<p>UPDATE: On further inspection there's a lot that I like about this one. The CLI design is neat, it builds on a strong underlying library (the OpenAI Codex implementation) and the features it does add - mainly the network proxy being able to modify headers to inject secrets - are genuinely great ideas.
> There are dozens of projects like this emerging right now. They all share the same challenge: establishing credibility.<p>Care to elaborate on the kind of "credibility" to be established here? All these bazillion sandboxing tools use the same underlying frameworks for isolation (e.g., ebpf, landlock, VMs, cgroups, namespaces) that are already credible.
The problem is that those underlying frameworks can very easily be misconfigured. I need to know that the higher level sandboxing tools were written by people with a <i>deep</i> understanding of the primitives that they are building on, and a very robust approach to testing that their assumptions hold and they don't have any bugs in their layer that affect the security of the overall system.<p>Most people are building on top of Apple's sandbox-exec which is itself almost entirely undocumented!
Simon! Thanks. I appreciate your comment and totally agreed. I will improve the docs as well as tests.
Personally I would probably always reach for a docker container if I want a sandboxed command that can run identically anywhere.<p>I appreciate that alternate sandboxing tools can reduce some of the heavier parts of docker though (i.e. building or downloading the correct image)<p>How would you compare this tool to say bubblewrap <a href="https://github.com/containers/" rel="nofollow">https://github.com/containers/</a>
I trust sandbox-exec more, or Docker on Linux. Those come from the OS, well tested and known.<p>MITM proxy is nice idea to avoid leaking secrets. Isn’t it very brittle though? Anthropic changes some URL-s and it’ll break.
Thanks for sharing that. Zerobox _does_ use the native OS sandboxing mechanisms (e.g. seatbelt) under the hood. I'm not trying to reinvent the wheel when it comes to sandboxing.<p>Re the URLs, I agree, that's why I added wildcard support, e.g. `*.openai.com` for secret injection as well as network call filtering.
You know, the thing is, that it is super easy to create such tools with AI nowadays. …and if you create your own, you can avoid these unnecessary abstractions. You get exactly what you want.
How do you intercept network traffic on mac os? How do you fake certificates?
Zerobox creates a cert in `~/.zerobox/cert` on the first proxy run and reuses that. The MTIM process uses that cert to make the calls, inject certs, etc. This is actually done by the underlying Codex crate.
the credential injection via MITM proxy is the most interesting part to me. the standard approach for agents is environment variables, which means the agent process can read them directly. having the sandbox intercept network calls and swap in credentials at the proxy layer means the agent code has a placeholder and never sees the real value -- useful when running less-trusted agent code or third-party tools.<p>the deny-by-default network policy also matters specifically for agent use: without it there is nothing stopping a tool call from exfiltrating context window contents to an arbitrary endpoint. most sandboxes focus on filesystem isolation and treat network as an afterthought.
Thanks and agreed! Zerobox uses the Deno sandboxing policy and also the same pattern for cred injection (placeholders as env vars, replaced at network call time).<p>Real secrets are never readable by any processes inside the sandbox:<p>```<p>zerobox -- echo $OPENAI_API_KEY<p>ZEROBOX_SECRET_a1b2c3d4e5...<p>```
Technical debt is not always bad. Deliberate technical debt taken on with eyes open to ship faster is a legitimate business strategy. The problem is accidental technical debt from poor decisions compounding silently.
Very interesting. I just started researching this topic yesterday to build something for adjacent use cases (sandboxing LLM authored programs). My initial prototype is using a wasm based sandbox, but I want something more robust and flexible.<p>Some of my use cases are very latency sensitive. What sort of overhead are you seeing?
I added a benchmark test (Apple M5) and on average I'm seeing 10ms overhead. I added a benchmark section to the repo as well <a href="https://github.com/afshinm/zerobox?tab=readme-ov-file#performance" rel="nofollow">https://github.com/afshinm/zerobox?tab=readme-ov-file#perfor...</a><p>Also, I'm literally wrapping Claude with zerobox now! No latency issues at all.
Again, it’s blacklisting so kind of impossible to get right. I’ve looked at this many times, but in order for things to properly work, you have to create a huge, huge, huge, huge sandbox file.<p>Especially for your application that you any kind of Apple framework.
This doesn't look like it's blacklisting to me. It's an allowlist system:<p><pre><code> --allow-net=api.openai.com # Explicitly allow access to that host
--allow-write=config.txt # Explicitly allow write to that file</code></pre>
That's interesting, thanks for sharing that. Could you elaborate a bit more? I'd like to understand the use case is a bit better.
You should probably add a huge disclaimer that this is an untested, experimental project.<p>Related, a direct comparison to other sandboxes and what you offer over those would be nice
I agree to some extend. I'm using the OpenAI Codex crates for sandboxing though, which I think it's properly tested? They launched last year and iterated many times. I will add a note though, thanks!
Cool project, and I think there would be a lot of value in just logging all operations.
For just logging would it really give any more info than a trace already does?
Forgot about that, was mostly thinking about how AI agents with unrestricted permissions would ideally have some external logging and monitoring, so there would be a record of what it touched. A trace has all of the raw information, so some kind of wrapper around that would be useful.
I'd like to know what level of details you'd expect. Something like `zerobox -- claude`, then you get an output log like this:<p>```<p>Read file /etc/passwd<p>Made network call to httpbin.org<p>Write file /tmp/access<p>```<p>etc.? I'm really interested to hear your thoughts and I will add that feature (I need something like that, too).
Agreed. I added the `--debug` flag this morning. It does simple logging including the proxy calls:<p>```<p>$ zerobox --debug --allow-net=httpbin.org -- curl<p>2026-04-01T18:06:33.928486Z CONNECT blocked (client=127.0.0.1:59225, host=example.com, reason=not_allowed)<p>curl: (56) CONNECT tunnel failed, response 403<p>```<p>I'm planning on adding otel integration as well.
This is more a criticism of codex's linux-sandboxing, which you're just wrapping, but it's the first I've ever looked at it. I don't see how it makes sense to invoke bwrap as a forked subprocess. Bubblewrap can't do anything beyond what you can do with unshare directly, which you can simply invoke as a system call without needing to spawn a subprocess or requiring the user to have bwrap installed. It kinds of reeks of amateur hour when developers effectively just translate shell scripts into compiled languages by using whatever variant of "system" is available to make the same command invocations you would make through a shell, as opposed to actually using the system call API. Especially when the invocation is crafted from user input, there's a long history of exploits arising from stuff like this. Writing it in Rust does nothing for you when you're just using Rust to call a different CLI tool that isn't written in Rust.
Thanks for sharing this, I read your comment multiple times. What would be the alternative though? It is true that the program being written in Rust doesn't solve the problem of spawning subprocesses, but what's the alternative in that case?
there's been so many of these -- which of these sandboxing tools is best?
[dead]