Show HN: Autobox – Make your agents sandbox themselves

First of all: this is NOT for folks who are already using a sandbox. The guarantees provided by Autobox are weaker. This is rather for folks who "hesitate" to use sandboxes.

Autobox is built around two observations I kept making over past one year of seeing sandbox launches and their real-world usage:

1. There are many sandboxing options now, and they work well. But leaving a handful few, almost nobody uses them. The blocker isn't the technology, it's the setup friction — however small it looks on paper, it's enough that people skip it entirely.

2. LLMs mostly don't write harmful code or take destructive steps. They're not adversarial by default.

Autobox bets on the second observation to remove the first. Instead of asking you to configure a sandbox, it's just there: every tool call carries its own permissions, and anything you don't explicitly allow is denied.

Is it perfect? No - seatbelt filesystem rules are best-effort, and the strong isolation is the V8 path.

Is it better than using no sandbox at all? Definitely yes.

This is also for M-series Macs only.

---

Oh, and the best part: "copy_then_sync":

Using APPFS `clonefile`, Autobox can hand your agent a full, "writable" copy of a repo instantly (1-2 ms). The agent gets something it can freely "destroy", but, your actual working tree is untouched. Your agent can then verify things, and of all looks okay, in one command sync the changes back to host within milliseconds.

Imustaskforhelp 27d ago ↗

At first, I had thought what is its point, but this post made me wonder about the fact that I myself don't use sandboxes (even though I very much think that they are a good option and recommend it to other people!)

I tried to use smolvm[0] on macOS and although its really great but then it was still a bit of an hassle to install maki.sh and It wasn't an entirely smooth sailing process in the start and I can see why there is some initial friction to it.

So I am gonna try it out as well and I think that this might be damn effective at what its trying to solve (simplifying sandboxing to be the norm rather than the exception)

For example. Even within Smolvm, I had to install maki (debug the issues in installing that as there were some errors), setup my api key in that, install gh, login to gh to finally have a working sandbox that can have my environment and I imagine that moving files from VM to host and vice versa is a tad-bit complicated without compromising on security (I think that I just create a private github repo for this purpose if its a coding project, which also helps in actually cataloging all the projects for myself as well!)

and in some way, I think that this can act as the bridge course between sandboxing as well, I mean, I have finally introduced sandboxing on my local machine (although for sometimes, I just treat my vps machines as sandbox but nonetheless there are times when I just run maki on my local machine and I think that even with smolvm I might still have this), I definitely see the point of it.

I haven't really tried it yet as it made me go rather on the smolvm side of things but hopefully going to try out this

This seems like a project and I have starred the repo, good day!

[0]: https://github.com/smol-machines/smolvm

freakynit 27d ago ↗

Thanks a lot. Really appreciate.

I have tried smolVM, bhatti.sh, naah and a few other sandboxes. And all of them have worked pretty well. But still, I rarely have kept using them. It's the friction part that discourage uses of such tools, not their usefulness.

This just aims to fix that. Not 100%, but, close.