Live data from Hacker News

Let's discuss sandbox isolation

shayon.dev

71–75 of 75 posts

Re: Let's discuss sandbox isolation

#71
post #3

OK, let’s survey how everybody is sandboxing their AI coding agents in early 2026. What I’ve seen suggests the most common answers are (a) “containers” and (b) “YOLO!” (maybe adding, “Please play nice, agent.”). One approach that I’m about to try is Sandvault [0] (macOS only), which uses the good old Unix user system together with some added precautions. Basically, give an agent its own unprivileged user account and…

There's an intermediate step, which is to use a combination of claude code sandboxing (bubblewrap), plus some pre tool hooks to look for sketchy commands, but it's still interactive and probably not the right longterm approach.

Re: Let's discuss sandbox isolation

#72

Earlier quoted context omitted.

Just posted about Qubes a minute after you did, but I don't find it painful or even time consuming. Initially there was a learning curve, but even if the security of Qubes became the same as the security of a baremetal OS, I would still use it. When I'm trying to get some software up and running, I've had issues with Debian many times, as well as with Fedora. Rarely with both. With Qubes after a few minutes of trying…

This is great insight - using Qubes as a "Super-OS" over other OSes. How does it fly performance-wise, what HW are you on or recommend ?

Sorry for the late reply.

I can't recommend specific HW as I'm not using anything new or beefy and I'm not running any CPU or GPU intensive things on Qubes.

There's the Qubes Hardware Compatibility List (HCL) where people have added their hardware:

https://www.qubes-os.org/hcl/

If and when I decide to upgrade, I'll also ask in the forums. Not all hardware supports all the features required for the security. Some hardware just doesn't play nice for one reason or another.

On my desktop I have an 8th gen Intel CPU with a motherboard that had good reviews for working well with Qubes. Nothing fancy. I rarely use CPU-heavy software, though. If I'm crunching some numbers like password cracking, I just assign a few more cores to a VM (VM is a "qube" with lowercase "q" in Qubes's terminology) than usual and let it run for a few days. But I rarely do that and when I did, I wasn't pressed for time, so I haven't had the need to optimize or bench anything so far. I can't speak as to how it would perform vs a baremetal OS. Probably worse, but not by much.

RAM is far more important, as least to me. 32 GB is what I consider the minimum for me, but I prefer 64 or more, as it lets me be more relaxed with how many VMs I have running. I'm usually at 30-40 GB used with ~20 VMs. But when I'm experimenting with something, I can run a bunch of other stuff and not run out.

Through trial and error I figured out what amount of RAM works for what types of VMs based on the usage. A VM with 1.5 GB RAM can open 50 or more tabs if you have JS off, or 2-3 shitty JS-ridden SPA vomit-inducing sites before it starts to lag. The good thing is that if a VM lags, only that VM lags; Qubes itself and other VMs don't.

With 16 GB you'd be fine, but you'll have to care more about how much RAM each VM has. For system VMs like network or USB VMs, or VMs you use for a specific purpose only it's easy to figure out the required RAM. Some may need as little as 300-400 MB.

Videos play fine on VLC with the integrated GPU. I have the same issues with VLC as I've had on baremetal Linux OSes on other computers, like stuttering for a few seconds after seeking backwards or not playing 1080p H.265 videos smoothly.

I don't have a dedicated GPU. I don't game or mine crypto or use CAD or run or train AI models. So I can't comment on anything GPU-related, such as drivers or passthrough or performance.

I have a few laptops with Qubes that I use from time to time. The oldest is an x230 Thinkpad from ~2012 with 16 GB RAM. I don't use it as a daily driver, though, just for a few specific things. As a daily driver 16 GB RAM would annoy me a bit, but I'd still make it work if that was my only chance.

Re: Let's discuss sandbox isolation

#73

Earlier quoted context omitted.

If you could make your tool work with PVM that would be amazing

Tool is already configured with paravirtualization on the linux path Unfortunately, the ecosystem and tooling is not there for macOS full paravirtualization yet

Oh neat yeah I only care about Linux pvm. Assuming we still have to have already installed the PVM kernel and other pvm-related prereqs or?

Re: Let's discuss sandbox isolation

#75
post #3

OK, let’s survey how everybody is sandboxing their AI coding agents in early 2026. What I’ve seen suggests the most common answers are (a) “containers” and (b) “YOLO!” (maybe adding, “Please play nice, agent.”). One approach that I’m about to try is Sandvault [0] (macOS only), which uses the good old Unix user system together with some added precautions. Basically, give an agent its own unprivileged user account and…

The interesting thing in that thread is how many people have landed on isolation as a workaround while still lacking a real control plane on top of it. Containers reduce blast radius, but they don’t answer approvals, policy, or auditability. That’s the gap I keep seeing in these setups. I've found a software, called Daedalab, that instead of sandboxing AI puts deterministic control on agents actions.
Post reply on HN