Show HN: Zerobox – Sandbox any command with file, network, credential controls

Posted by afshinmeh 2 days ago

Show HN: Zerobox – Sandbox any command with file, network, credential controls(github.com)

I'm excited to introduce Zerobox, a cross-platform, single binary process sandboxing CLI written in Rust. It uses the sandboxing crates from the OpenAI Codex repo and adds additional functionalities like secret injection, SDK, etc.

Watch the demo: https://www.youtube.com/watch?v=wZiPm9BOPCg

Zerobox follows the same sandboxing policy as Deno which is deny by default. The only operation that the command can run is reading files, all writes and network I/O are blocked by default. No VMs, no Docker, no remote servers.

Want to block reads to /etc?

  zerobox --deny-read=/etc -- cat /etc/passwd

  cat: /etc/passwd: Operation not permitted

How it works:

Zerobox wraps any commands/programs, runs an MITM proxy and uses the native sandboxing solutions on each operating system (e.g BubbleWrap on Linux) to run the given process in a sandbox. The MITM proxy has two jobs: blocking network calls and injecting credentials at the network level.

Think of it this way, I want to inject "Bearer OPENAI_API_KEY" but I don't want my sandboxed command to know about it, Zerobox does that by replacing "OPENAI_API_KEY" with a placeholder, then replaces it when the actual outbound network call is made, see this example:

  zerobox --secret OPENAI_API_KEY=$OPENAI_API_KEY --secret-host OPENAI_API_KEY=api.openai.com -- bun agent.ts

Zerobox is different than other sandboxing solutions in the sense that it would allow you to easily sandbox any commands locally and it works the same on all platforms. I've been exploring different sandboxing solutions, including Firecracker VMs locally, and this is the closest I was able to get when it comes to sandboxing commands locally.

The next thing I'm exploring is `zerobox claude` or `zerobox openclaw` which would wrap the entire agent and preload the correct policy profiles.

I'd love to hear your feedback, especially if you are running AI Agents (e.g. OpenClaw), MCPs, AI Tools locally.

57 points | 61 commentspage 2

EGreg 2 hours ago|

This is really useful! How well does it compare though to Docker etc.

Because I am worried about sandbox escapes. This is what we currently use to sandbox JS inside Browsers and Node (without anything extra) : https://github.com/Qbix/Platform/blob/main/platform/plugins/...

I like tools like this, but they all seem to share the same underlying shape: take an arbitrary process and try to restrict it with OS primitives + some policy layer (flags, proxies, etc).

That works, but it also means correctness depends heavily on configuration, i.e. you’re starting with a lot of ambient authority and trying to subtract from it enforcement ends up split across multiple layers (kernel, wrapper, proxy)

An alternative model is to flip it: Instead of sandboxing arbitrary programs, run workflows in an environment where there is no general network/filesystem access at all, and every external interaction has to go through explicit capabilities.

In that setup, there’s nothing to "block" because the dangerous primitives aren’t exposed, execution can be deterministic/replayable, so you can actually audit behavior. Thus, secrets don’t enter the execution context, they’re only used at the boundary

It feels closer to capability-based systems than traditional sandboxing. Curious how people here think about that tradeoff vs OS-level sandbox + proxy approaches.

afshinmeh 1 hour ago|

Zerobox uses the same kernel mechanisms (namespaces + seccomp) but no daemon, no root and cold start ~10ms (Docker is much worse in that regard).

Docker gives you full filesystem isolation and resource limits. Zerobox gives you granular file/network/credential controls with near zero overhead. You can in fact use Zerobox _inside_ Docker (e.g. for secret management)

alyxya 4 hours ago||

Cool project, and I think there would be a lot of value in just logging all operations.

kimixa 4 hours ago||

For just logging would it really give any more info than a trace already does?

alyxya 3 hours ago|||

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.

afshinmeh 3 hours ago||

I'd like to know what level of details you'd expect. Something like `zerobox -- claude`, then you get an output log like this:

```

Read file /etc/passwd

Made network call to httpbin.org

Write file /tmp/access

```

etc.? I'm really interested to hear your thoughts and I will add that feature (I need something like that, too).

kimixa 13 minutes ago|||

*strace that is - annoyingly it seems it was autocorrected away

afshinmeh 4 minutes ago||

I think there is still a valid case for sandbox logs/otel. strace would give you the syscalls/traces but not _why_ a particular call was blocked in side the sandbox (e.g. the decision making bit).

afshinmeh 3 hours ago||

Agreed. I added the `--debug` flag this morning. It does simple logging including the proxy calls:

```

$ zerobox --debug --allow-net=httpbin.org -- curl

2026-04-01T18:06:33.928486Z CONNECT blocked (client=127.0.0.1:59225, host=example.com, reason=not_allowed)

curl: (56) CONNECT tunnel failed, response 403

```

I'm planning on adding otel integration as well.

nonameiguess 2 hours ago||

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.

simonw 1 hour ago||

Is your criticism here that there's no point in invoking bwrap directly when you could instead implement the same things that bwrap implements?

I'd much rather a system call bwrap than re-implement bwrap, because bwrap has already been extensively tested.

afshinmeh 1 hour ago||

That was my thinking, too. The only other option would be reimplement it in Rust (never researched what exists though).

afshinmeh 2 hours ago||

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?

gigatexal 2 hours ago||

there's been so many of these -- which of these sandboxing tools is best?

_pdp_ 2 hours ago|

Not a single one. All of them are solving the obvious (and wrong) problem.

simonw 1 hour ago|||

What's the right problem to be solving here?

afshinmeh 1 hour ago|||

I'd love to learn more please. I'm interested in sandboxing AI tools/agents regardless of the underlying mechanism (I explored Firecracker VMs briefly as well, terrible cross platform support though).

MarcelinoGMX3C 2 hours ago||

[dead]