afshinmeh

No, it's stateless right now. What is your requirement though? How do you define a session? Are you referring to "snapshotting" between sessions?

On macOS, the proxy is best effort. Programs that ignore HTTPS_PROXY/HTTP_PROXY can connect directly. This is a platform limitation (macOS Seatbelt doesn't support forced proxy routing).

BUT, the default behaviour (no net) is fully enforced at the kernel level. Domain filtering relies on the program respecting proxy env vars.

Ohh! thanks for sharing this. You are using DNS proxy which is interesting and useful if a process doesn't respect the HTTPS_PROXY/HTTP_PROXY/etc. env vars that I'm injecting. I will take a look, very interesting.

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).

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)

Great question! On Linux, yes, network namespaces enforce that and all net traffic goes through the proxy. Direct connections are blocked at the kernel level even if the program ignores proxy env vars, but I will test this case a bit more (unsure how to though, most network calls would respect HTTPS_PROXY and other similar env vars).

That being said, the default behaviour is no network, so nothing will be routed if it's not allowed regardless of whether the sandboxed process respects env vars or not.

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?

Give me 2 days :)

Oh I see. It inject HTTP_PROXY/HTTPS_PROXY/etc. env vars into the process so that all sandboxed subprocesses go through the proxy.

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.

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).

Not sure. I took this idea from the Deno sandboxing docs. They also do the exact same thing, different sandboxing mechanism though (I think Deno has it's own way of sandboxing subprocesses).

Fantastic! I like that idea. I'm also exploring an option to define profiles, but also have predefines profiles that ships with the binary (e.g. Claude, then block all `.env` reads, etc.)

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.

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.

I agree and you can deny all reads like this:

```

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

```

That being said, what the default DX shouldl be? What paths to deny by default? That's something I've been thinking about and I'd love to hear your thoughts.

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).

Real secrets are never readable by any processes inside the sandbox:

```

zerobox -- echo $OPENAI_API_KEY

ZEROBOX_SECRET_a1b2c3d4e5...

```

That's correct. The pattern is: reads allowed, write and network I/O blocked by default.

```

zerobox -- curl https://example.com

Could not resolve host: example.com

```

That's right. It uses the same kernel mechanisms as Docker, the runtime is different though (bwrap on linux, seatbelt on mac, etc.)

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.

Simon! Thanks. I appreciate your comment and totally agreed. I will improve the docs as well as tests.

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!

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 https://github.com/afshinm/zerobox?tab=readme-ov-file#perfor...

Also, I'm literally wrapping Claude with zerobox now! No latency issues at all.

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.

ClawRun would deploy the agent on a sandbox. Think of it as a super lightweight environment running your workload. EC2 gives you a full VM which means slow boots, manual cleanup, big blast radius if your agent breaks out. You manage everything, AMIs, security groups, teardown.

ClawRun manages that entire lifecycle for you including the snapshotting, firewall configuration, etc.

I'm building the JavaScript version of Semantic Kernel: https://kerneljs.com

> Semantic Kernel is a lightweight, open-source development kit that lets you easily build AI agents and integrate the latest AI models. It serves as an efficient middleware that enables rapid delivery of enterprise-grade solutions.

Hey HN! I’ve been working on bringing Semantic Kernel to the JavaScript/TypeScript world, and just published the first usable version. It’s designed to make it easier to build AI agents and workflows using OpenAI, local models, and plugins, all in JS.

This version focuses on simplicity, clean APIs, and being lightweight enough to run in browser and server environments (like Cloudflare Workers or Vercel). Still early days, but feedback and contributions are super welcome!

Repo: https://github.com/afshinm/semantic-kernel-js Docs: https://kerneljs.com/

Let me know what you think or if you have ideas / use cases in mind.

Looks great! Tried a few examples and models, works very well.

Nice! thanks for using https://gridjs.io :)

I have built https://gridjs.io on top of Preact. It's pretty stable and the API is very nice. Supports most events/callbacks that React has (nothing against Hyperapp though)

Hey Simonw! I fixed both issues with the column/table width and published v1.1.1. See: https://observablehq.com/@afshinmeh/grid-js-with-datasette?u...

Please take a look and let me know what you think!