I use Leash [1] [2] for sandboxing my agents (to great effect!). I've been very happy with it, it provides much strict policy-level control for both process-level + network-level activity, as well as full visibility with a nice UI and dynamic runtime controls via WebUI. Way better than bubblewrap imo.
I originally saw it here on HN and have been hooked ever since.
Fun fact: Do you know what container / sandboxing system is in most widespread use? Not docker containers, certainly not bubblewrap, and not even full VMs or firecracker. It's Chrome tabs.
I don't know if I want to create an ad-hoc list of permissions. What I would like would be something like take a snapshot of my current workspace in a VM. Run claude there and let it go wild. After the end of the session, kill the box. The only downside is potentially syncing the claude sessions/projects. But I don't think that'd be too difficult.
> Bubblewrap and Docker are not hardened security isolation mechanisms, but that's okay with me.
Edit to add: my understanding is the major flaw in this approach is potential bugs in Linux kernel that would allow sandbox escape. Would appreciate your insight if there are some easier/more probable attack vectors.
I will ask what I've asked before: how to know what resources to make available to agents and what policies to enforce? The agent behavior is not predefined; it may need access to a number of files & web domains.
For example, you said:
> I don't expose entire /etc, just the bare minimum
How is "bare minimum" defined?
> Inspecting the log you can spot which files are needed and bind them as needed.
This requires manual inspection.
Article author here. I used trial and error - manual inspection it is.
This took me a few minutes but I feel more in control of what's being exposed and how. The AI recommended just exposing the entire /etc for example. It's probably okay in my case, but I wanted to go more precise.
On the network access part, I let it fully loose (no restrictions, it can access anything). I might want to tighten that in the future (or at least disallow 192.168/16 and 10/8), for now I'm not very concerned.
So there's levels of how tight you want to set it.
As a heads up and affirmation that the approach is correct, here's a small shell bubblewrap wrapper that boils the command line down to `sandbox-run claude --dangerously-skip-permissions`.
`ssh localhost` doesn't work for me. maybe because I have enabled only key-based ssh and my user key is not in authorized_keys? am I missing something?
I'm launching a SaaS to create yet another solution to the AI Sandboxing problem in linux.
My friends and I have spent a lot of time quietly injecting support down into the kernel without anybody raising a flag, and we finally have the infrastructure in place to solve this problem.
We have also poisoned all the LLMs training data with our approach, so our marketing is primed and we wont even need to learn Claude to use our tool.
We’re planning a soft launch this month, or maybe next month. Depending on how "in the vibe" (our new word for flow :) our team gets.
We’re calling it `useradd`.
Yes, the man page is intimidating, and the documentation is terrible. But once you're over the learning curve, it puts your machine into a kind of 'main frame' mode where multiple 'virtual teletypes' and users can operate on the same machine.
DM me if you want a beta key.
---
Sorry for the snark, but i cringe at the monuments to complexity I see people building, at least this solution is relative simple and free. Still, dont really see what it buys me.
I get where this is coming from, and it's not a terrible solution, but VMs are still better in terms of security and isolation. Typical workstation systems are not designed to be secure from their own users, and frontier models are going to get scary good at cracking systems soon.
I love using different users for separating services I run on the same box!
For development, I want to be able to access/run/modify/delete the files alongside the AI agent. This can be done if groups and group permissions are set correctly (and the agent correctly chmods everything...), but that feels more fiddly than just isolating it with bubblewrap, systemd, or whatever, and preserving the uid/gid.
I have used a separate user, but lately I have been using rootless podman containers instead for this reason. But I know too little about container escapes. So I am thinking about a combination.
Would a podman container run by a separate user provide any benefit over the two by themselves?
I'd been thinking of using toolbox or devcontainers going forward, but having to craft containers with all my stuff sounds so painful, feels like it would become another full-time job to make containers
Bubblewrap & passing in a bunch of the current system sounds like a great compromise!
I do wonder what isolation something like systemd-run can offer, if that is enough.
Part #2 to me, I also want observability as to what the agent changed. That was one place where containers are such a clear & huge advantage! Having an overlay that contains the changes to the filesystem is so explicit. There's also works like agentfs, that offer a FUSE filesystem backed by Turso DB (sqlite compatible).
I use Leash [1] [2] for sandboxing my agents (to great effect!). I've been very happy with it, it provides much strict policy-level control for both process-level + network-level activity, as well as full visibility with a nice UI and dynamic runtime controls via WebUI. Way better than bubblewrap imo.
I originally saw it here on HN and have been hooked ever since.
[1] Screenshot: https://camo.githubusercontent.com/99b9e199ffb820c27c4e977f2...
[2] https://github.com/strongdm/leash
Fun fact: Do you know what container / sandboxing system is in most widespread use? Not docker containers, certainly not bubblewrap, and not even full VMs or firecracker. It's Chrome tabs.
Using Chrome for anything seems like a security failure of itself. It's got great features, but damn do they come at a cost.
I don't know if I want to create an ad-hoc list of permissions. What I would like would be something like take a snapshot of my current workspace in a VM. Run claude there and let it go wild. After the end of the session, kill the box. The only downside is potentially syncing the claude sessions/projects. But I don't think that'd be too difficult.
I recently blogged about how I do this using MicroVMs on NixOS: https://michael.stapelberg.ch/posts/2026-02-01-coding-agent-...
> take a snapshot of my current workspace in a VM. Run claude there
Sounds like docker + overlayfs might fit the bill, as long as there's a base image that is close enough to what you need.
I don't think there should be One True Way how to run these, everyone can set it up in a way that best fits their workflow.
both Docker and bubblewrap are not secure sandboxes. the only way to have actually isolated sandboxes is by using VMs
disclaimer: i work on secure sandboxes at E2B
No disagreement from me. From the article:
> Bubblewrap and Docker are not hardened security isolation mechanisms, but that's okay with me.
Edit to add: my understanding is the major flaw in this approach is potential bugs in Linux kernel that would allow sandbox escape. Would appreciate your insight if there are some easier/more probable attack vectors.
Do you have more information on how to set up such VMs?
for personal use, many ways: Vargant, Docker Sandbox, NixOS VMs, Lima, OrbStack.
if you want multi-tenant: E2B (open-source, self-hosted)
I will ask what I've asked before: how to know what resources to make available to agents and what policies to enforce? The agent behavior is not predefined; it may need access to a number of files & web domains.
For example, you said: > I don't expose entire /etc, just the bare minimum How is "bare minimum" defined?
> Inspecting the log you can spot which files are needed and bind them as needed. This requires manual inspection.
Article author here. I used trial and error - manual inspection it is.
This took me a few minutes but I feel more in control of what's being exposed and how. The AI recommended just exposing the entire /etc for example. It's probably okay in my case, but I wanted to go more precise.
On the network access part, I let it fully loose (no restrictions, it can access anything). I might want to tighten that in the future (or at least disallow 192.168/16 and 10/8), for now I'm not very concerned.
So there's levels of how tight you want to set it.
> I feel more in control of what's being exposed and how
Makes complete sense. Thanks for your insights!
Ask the agent to bubblewrap itself
I like this approach for Nix: https://dev.to/andersonjoseph/how-i-run-llm-agents-in-a-secu... It makes it also easy to give the agent only access to the tools it actually needs.
As a heads up and affirmation that the approach is correct, here's a small shell bubblewrap wrapper that boils the command line down to `sandbox-run claude --dangerously-skip-permissions`.
https://github.com/sandbox-utils/sandbox-run
If you have ssh installed, with network access it can ssh localhost to escape the sandbox.
You can consider these agents criminals, or treat them like babies. Both can do harm for a while, but one offers a future.
Don't give it access to your ssh keys!
Yes, it should have its own dedicated key instead of sharing one of your own.
`ssh localhost` doesn't work for me. maybe because I have enabled only key-based ssh and my user key is not in authorized_keys? am I missing something?
You are right in that it would still need to authenticate.
I'm launching a SaaS to create yet another solution to the AI Sandboxing problem in linux.
My friends and I have spent a lot of time quietly injecting support down into the kernel without anybody raising a flag, and we finally have the infrastructure in place to solve this problem.
We have also poisoned all the LLMs training data with our approach, so our marketing is primed and we wont even need to learn Claude to use our tool.
We’re planning a soft launch this month, or maybe next month. Depending on how "in the vibe" (our new word for flow :) our team gets.
We’re calling it `useradd`.
Yes, the man page is intimidating, and the documentation is terrible. But once you're over the learning curve, it puts your machine into a kind of 'main frame' mode where multiple 'virtual teletypes' and users can operate on the same machine.
DM me if you want a beta key.
---
Sorry for the snark, but i cringe at the monuments to complexity I see people building, at least this solution is relative simple and free. Still, dont really see what it buys me.
I get where this is coming from, and it's not a terrible solution, but VMs are still better in terms of security and isolation. Typical workstation systems are not designed to be secure from their own users, and frontier models are going to get scary good at cracking systems soon.
I love using different users for separating services I run on the same box!
For development, I want to be able to access/run/modify/delete the files alongside the AI agent. This can be done if groups and group permissions are set correctly (and the agent correctly chmods everything...), but that feels more fiddly than just isolating it with bubblewrap, systemd, or whatever, and preserving the uid/gid.
Just my 2c - it's great that we have options!
Well done. It took me all the way up to `useradd`...
Edit: too bad about your edit. The comment was just fine without it.
I wrote my comment to vent my disdain for all the circus projects filled with marketing blurbs and features lists for their overengineered vibeslop.
OP is just sharing the cool utility he found, and how it solved a problem for him.
It felt bad to leave them with the message they shouldn't have, or that he's a big part of the problem.
OP here, no worries, loved the comment and appreciate the feeling :)
`useradd` doesn't restrict network access.
I have used a separate user, but lately I have been using rootless podman containers instead for this reason. But I know too little about container escapes. So I am thinking about a combination.
Would a podman container run by a separate user provide any benefit over the two by themselves?
Would love this for MacOS
There's https://code.claude.com/docs/en/sandboxing that uses something called Seatbelt on Mac and bubblewrap (the same thing I used here) on Linux.
No idea how customizable that is.
My app does this on macOS! https://multitui.com
Saw something last week using bubblewrap as well in hn github.com/Use-Tusk/fence
Really well targeted!
I'd been thinking of using toolbox or devcontainers going forward, but having to craft containers with all my stuff sounds so painful, feels like it would become another full-time job to make containers
Bubblewrap & passing in a bunch of the current system sounds like a great compromise!
I do wonder what isolation something like systemd-run can offer, if that is enough.
Part #2 to me, I also want observability as to what the agent changed. That was one place where containers are such a clear & huge advantage! Having an overlay that contains the changes to the filesystem is so explicit. There's also works like agentfs, that offer a FUSE filesystem backed by Turso DB (sqlite compatible).