The login is annoying but, lacking an open source alternative, this has been my daily driver for a while now because it works great out of the box with two key features: outbound firewall and secret injection with placeholders.
I run it with superset and then each git worktree is mounted in a sandbox that is configured for each repo i work in.
I use Linux Containers managed by Incus for working with Claude.
I have a dedicated container for that. It can run its own Docker daemon and other system services if needed.
Apart from the Claude login token, it has no SSH keys or other credentials. I push everything I need to it from the local machine. And I pull the Claude generated outputs from it.
Of course, this kind of setup requires a stack which can run or at least be tested without any credentials.
Agreed. Network control and secret injection together with a microVM setup is as good as it gets right now, although I believe that we need more fine-grained tools down the road. It sounds like Microsandbox would be the perfect fit for what you are describing. I also built my own coding agent workbench on top of it (https://github.com/isolade/isolade). Microsandbox is quite cool, check it out: https://github.com/superradcompany/microsandbox
Has egress and ingress filtering, egress can be bound to host/internet/subnet or even better to internal apps (which are each separate netns) meaning you can do your own firewall/vpn/whatever per sandbox. Plus you control what other components in the sandbox env the app can communicate with.
Really not built for day-to-day dev work though, more like automating your company/life / getting rid of SaaS (e.g. for technical Founders / Sales etc, not exactly useful for dev work)
Eclipse Enclave does exactly that: There is an outbound firewall and secret injections, so that the agent never sees a real key. And it's fully open source: https://github.com/eclipse-enclave/enclave
What is missing in qemu + podman that we need rootful docker for this? Is there actual capability that is missing or is it more of a design choice by the eclipse enclave folks?
If you just need a python+venv sandbox with dev-first UX, no container build step needed, and no startup cost then I am using https://github.com/nzjrs/sandbubble in prod.
I've put some effort to integrate it to my agentic workflow. The problem, however, with docker in smolvm: it work-ish (there is example), but quite hacky.
Another problem which I wasnt able to solve - persistent image without Dockerfile. CloudInit will be ideal.
Documention at this moment in an early stage.
Overall, its a great project but for me was simpler just use Virtual Machine Manager (libvirt GUI).
I wish all luck to the maintainers, but probably DX-wise I will prefer to have more granular or predictable controls (eg micro cloud from Canonical).
I havent used nor gondolin neither docker's solution, but curious to know what gondolin is missing (evaluating both for my personal use)? is it only the DX or something else, if DX, can you what exactly is missing?
You can run the agent in the gondolin sandbox if you wish.
Their example implementation with pi uses a pi extension so that pi runs on the host but the read/write/bash/etc tools run in the guest. Doesn’t have to be that way though.
Does secret injection really prevent that the agent send my GitHub key somewhere? If it has access to it via env var, can it not just paste it somewhere?
https://github.com/pjlsergeant/byre -- slightly different security model, but lazer-focused on developer experience; my daily driver and I love it not just because I wrote it. The TUI is great for configuring and setting up instant boxes just how you want
https://pleasedonotescape.com/ -- a list of every other agent jail I could find, filterable by open-source and whatever else you want
What I run is one hardened QEMU/KVM VM per project holding the whole dev environment (editors, agents, containers), with nftables on the host allowing internet egress but dropping anything aimed at the host, the LAN, or any other private address, plus an allowlist for deliberate exceptions.
Basically, it's a plain QEMU/KVM VM on a stock Debian cloud image: device model stripped down to a virtio disk, a virtio NIC and a serial console, nested virt off, no passwordless sudo in the guest. It also ships a containment check that scans outward from inside the guest, so the network boundary is something you can verify.
Wrapping the whole environment rather than a single agent session puts supply chain attacks inside the boundary too. A poisoned npm or PyPI package, or a compromised editor extension, lands in the VM instead of on the host. That was the original reason I set this up; agents just made it more urgent.
There's no per-domain egress allowlist; the policy is "internet yes, private addresses no". Secret injection isn't built in either, though Infisical's agent-vault on the host as an egress proxy covers that part.
Wrote the whole setup up here, in case it's useful:
“microvms” are real vms but the hypervisor and vm (guest kernel) shed most of the hardware / device emulation, support, and discovery which makes traditional VMs look / feel like real computers, as well as most guest interactions. This gives them extremely low overhead.
Firecracker is designed to start a VM in under 125ms and 5MB. Netbsd advertises that you can direct-boot a MICROVM kernel configuration in under 10ms.
There’s also memory hotplugging via virtio-mem. But generally speaking downscaling live vm memory can’t be said to be a solved problem, it’s more of an active area of research.
Your example is not complete, you have to show how it will run claude/codex, you have to do extra things to install run and mount folders there, this one does that with less config, also with this agents can run docker, lxd doesn't allow you to do that
There are many devs that have little to no experience of Linux, like the hundreds of thousands of .Net and Java CRUD devs in enterprise companies using Windows.
There is a need for a Docker desktop like GUI for this market.
When I was a teen I had no experience with software development. Then I went to school and learned about it. Now I'm making money doing this thing because I became quite good.
The world didn't fit around me, so I made "me" fit around "the world". I bet those stubborn dinosaurs can learn a new trick or two also, if management lets them do it during working ours...
Also, WSL (Windows Subsystem for Linux) has been baked into Windows for a long time and makes it very easy to play with Linux, as does using the Hyper-V VM system. Any developer unfamiliar with Linux because they use Windows, has little excuse.
An Ubuntu Server VM, like the ones started by Incus, use at least 512 MB of RAM per instance. If you spawn 10 sandbox VMs, you already pay 5 GB RAM just to sit there idle. You also pay a CPU cost, you have 10 kernels managing stuff, but arguably it doesn't matter that much given CPU core counts.
I use something in between - a single Ubuntu VM, into which I spawn multiple Incus LXC containers for the agents. The containers only use 50 MB or so per instance (separate systemd, ...). This way I pay the VM RAM tax only once, and the agents are still contained inside the VM if they manage to escape the LXC containers.
Yes, bubblewrap is superior to Docker for this. I wrote a tool to use bubblewrap for the purpose. It needs a tool to start it, or is at least much more convenient with a tool, because you need to take your session/auth data into the container, and if you want the agent to be able to start containers (agents love containers) within the container, you need some config magic mounted inside. You could manually do all that, or do it with a shell script, as well. But, this is how I did it, and you're likely to run into all the same little quirks I ran into:
I just made my own devcontainer that I copy on any project and load whatever harness I want in that repo. Harnesss' config and auth are simply mounted from the host, so no setup required at all.
Does this support Linux yet? When I previously looked it did not (the reason being that they were already using VMs on Windows/macOS but not on Linux). Every time I see an announcement I think "great, they must've added Linux now then", but the linked pages always have Windows + macOS instructions but not Linux.
All the open GH issues about supporting Linux that I subscribed to have gone unresponded to.
OpenShell looks like a good alternative, but it still has "Do not use in production" plastered all over the website, which doesn't fill me with confidence yet
I wrote a tool to use `bubblewrap` to containerize any agent (at least all the agents I've used a couple of times), and bind mount the system stuff read-only, so the agent has your "usual" environment, but they can only see the project. Their history persists (either through a bind mount or a "shadow" copy of the history that only the wrapped agent sees), the agent can still create and manage containers of its own using podman's rootless mode, etc. It's nearly instant to start because it's just a namespace (plus a few copied files for the container support and session history); no container needs to be built/fetched/updated/whatever. bubblewrap is extremely well-tested as it is used by flatpak and several other large projects, so I trust it quite a bit (more than I trust Docker).
I also hit the same issue recently. No Linux and no Windows on arm. AI sandboxing has a lot of options but none feel complete just yet. It's hard to commit to something, especially if reviewing tools to aide in company policies.
Regardless, I'm hoping something that isn't behind a login screen is going to win out.
I got excited for this not because this didn't exist before, but because Docker putting their weight on this would imply a broader adoption and better integration in the industry. I am sad that they are asking for a login here though, which doesn't make any sense to me.
Models start going to extreme, damaging lengths to achieve ambiguous prompts[0]. Having good sandboxes is now a must IMO.
But sbx is a bit annoying to use with OpenCode for instance (which has zero sandboxing by default, unlike codex CLI or Claude Code). You cannot easily change ~/.config/opencode/opencode.jsonc AFAIK.
I have a solution based on Nix that can be used to generate reproducible container images: https://github.com/nothingnesses/agent-images . It lets you customise which agents, harnesses, or any other packages you want included in the VM and it uses `agent-box` for sandboxing.
It's a batteries included alternative to firecracker with a couple of new ideas tossed into the mix i.e. portable like a container (bake into a single file and rehydrate the vm anywhere), dynamic resource allocation, etc.
Anyone serious about security will want to bring their own sandbox anyway, not trust these, often proprietary, agents. I've never run an agent outside a sandbox. My first bubblewrap script for `claude` is now over a year old. The tools are available and if you learn to use them you can run any program in a sandbox.
But, in any case, why put in effort doing something people don't expect or ask for? We can assume everyone running agents is either a) using their own sandbox, or b) doesn't care. I think we can guess which category most people fall into. You could maybe argue about responsibility, but I don't think you can argue about "serious engineering".
> Anyone serious about security will want to bring their own sandbox anyway
Exactly. It's not as though it's difficult. It never occurred to me to not do this from day one, and it astonishes me that anyone runs this stuff bare metal. Since then, I've brought several other people on board, and that's all they've ever seen: I don't think they'd know how to run outside a sandbox, and that's just fine.
Eg, if used with Colima in macOS, it means I can run a devcontainer in an isolated VM and Nono inside the devcontainer can restrict a lot what can and cannot be done.
You get credentials proxying and network outbound limits.
Before you use no sandbox at all use this or one the many similar projects but it's alway worth remembering that Docker is not a security boundary. It never has been meant to be and never will
become one.
cgroups are a mechanism designed for hierarchical organization and resource distribution. Against a malicious and capable actor, and that is how we have to treat AI agents, cgroups will not withstand.
Also, the kernal is an interface too big for what an AI agent needs and is therefore offering a gigantic attack surface completely unnecessarily.
Wouldn't it need a super critical exploit, I mean zero-day vulnerability, to escape from that kind of sandbox ? And if you think further, then isn't that risk also applicable to pretty much any kind of sandboxing ?
Container escapes are more common than you think. Common enough for AWS not to rely on containers for their serverless functions, common enough for Google to say: "Untrusted code shouldn't rely on the container security boundary [..]" [1]
The same is not applicable for any kind of sandboxing for two reasons:
1. The boundary is in the kernal’s own code, enforced by the thing you are trying to be protected from. -> Use a VM
2. The kernal is a gigantic attack surface -> Use gVisor
Can someone more versed in Docker explain to me how this is different than building my own docker container from a Dockerfile for using Pi agent harness? That's what I do currently. I use Docker Desktop in windows as the backend for that.
Docker containers use Linux kernel features to create an isolated environment, running on the same machine as docker is.
This creates a virtual machine, with its own kernel, and runs the container in there.
This gives stronger isolation and security guarantees.
I have the same question as GP. Your answer helps a little but not really. I might be naive, but I was under the impression that malicious code escaping a docker image and running amok on my host system was not something I should be too worried about. Especially if I run docker in rootless mode. Is that wrong?
For clarity I’m actually using podman, not Docker.
Oh no, you should definitely be worried about that. Podman might make it harder to escalate to host root, or manipulate other containers, but it is still vulnerable.
Now I'm curious to know how hardened the Docket Sandbox orchestration interface is. I guess we can assume they have run Mythos against it for a few weeks maybe? It's unclear.
Unsettling. I mean, is there any reasonable way to develop software in 2026? I've already sworn off ever installing npm directly on my host. Containerizing everything is laborious enough, but running a separate VM for everything?
You just need to work out the threat model for what you're working on. For trusted containerized workloads, where the attack surface is minimal, just containerization is fine. However, agents can do just about anything on your computer if you allow it and people aren't really shying away from `--dangerously-skip-permissions`, so better hardening (VMs, microVMs) is desirable.
Unless we're talking 0-day/CVE, running an unprivileged container is as trustable as a VM. The only difference is how strictly you want to hold the memory/CPU bar. Infact on linux, containers are more lightweight than VMs.
I know some people want to run their agents when their computer is off, but I imagine a solution like this will be much more common than paying for a remote sandbox (i.e on fly.io or exe.dev), especially because it'll be free.
Though, they need to remove the login requirement.
The sandboxing problem is perhaps the greatest justification for doing agent integration via existing human interfaces rather than low level shell access. Granting access to shell is a super obvious path (it's easy) so I can understand us wanting to fight for it. But we should consider the other paths as well before we make our final stand.
Automating browsers with LLM agents properly requires a lot more work than Process.Start into powershell, but the advantages can be immense once you have achieved integration this way. Incrementally maintaining this integration is generally easy because human users cannot tolerate rapid changes either.
It's a hell of a lot easier to convince management to adopt a robot that looks and acts like a human employee than one that looks like a combine harvester. The combine is far more efficient, but it is also totally indiscriminate. Nothing constrains its appetite except for the invisible fence imposed by GPS. The amount of infrastructure required to keep farm equipment from running astray is incredible. In the context of agriculture, the added complexity is definitely worth it. We don't want to have to recreate the same thing with our technology if it can be avoided. Sandboxes and security isolation boundaries are not things to aspire to. These are costs to be paid for admission to something more valuable.
I tried Docker Sandboxes but last time I checked you could not configure custom volume mounts, making more complex setups impossible. For work I need two directories for context for the agent to have access to…
I'm confused:
1. If I run this on Mac, then inside the sandbox / microVM, am I still running MacOS or some Linux distribution?
2. If the only thing that's mounted from the host is the $PWD, how does it guarantee that it has all the system libraries that I have installed on my host system? e.g. my `/opt/homebrew` libraries or `sudo apt install libfoo-dev` headers
I did try to use those for some stuff:
* Login requirement is something else
* It's closed source last I checked
* Pretty slow/unstable
There are many better namespace/container based options, VMs may be moderately more secure but when you more or less trust your agent and code you can do with lesser containment. And with the recent CVEs in kvm honestly there isn't a huge deal of difference vs namespaces.
(I'm building https://xbin.dev/ for some time now for managing my personal code/apps, a project which started specifically after Docker Sandboxes broke on me some time ago)
I use it (sbx), but I don't 100% trust that it actually works, and I would prefer something open source where the limits of the sandboxing could be tested and explored.
Maybe we should just ssh into separate development machines to ensure real and verifiable sandboxing? (as was totally standard before Docker became a thing)
Doesn't everyone do this now? It's hardly a new idea. Yet every time someone proposes the idea, people fawn over it and proclaim it the best thing ever.
Yes, you can inject tokens via a proxy. What else is new?
Who is doing it as first class feature with at least adequate UX?
I have skimmed alternatives offered in comments to this post (vibepod-cli, code-on-incus, opencode-docker, sandboxy, smolvm, amazing-sandbox) and none of them seem to do credentials injection at the proxy level.
Just a small meta note: most of the comments in this thread appear to be posting their own codebase (typically AI-generated) that accomplishes the same goal. It's interesting that this problem is simultaneously in high demand and yet considered trivial enough to vibe code per-user solutions to it.
Like many people, I suspect, I used Claude to write my own agent sandbox that suits my needs very well. Investing my time in a propietary product has become a hard sell.
I did the same thing. It was my first "vibecoded" project. I've been using it every day and it's great. I'm writing a custom Rust network stack for it right now. Gonna replace the current nftables firewall with it.
As for Docker Sandboxes, I'll just ask Sol literally right now to see what it does better than my virtdev, and then I'll improve virtdev instead of using Docker.
> Were you following any patterns/standards/advice on what you needed to protect against?
Just the general knowledge that sharing a kernel with untrusted software is too dangerous, that hardware virtualization is an infinitely smaller attack surface and that the entire industry will be in deep shit if people or AI breaks hypervisors.
Initial threat model was supply chain attacks but eventually grew to include AI harnesses as well. Not very worried about them hacking me, more about accident prevention.
So that means each VM must be running a completely independent kernel that's fully isolated from the host's file system. They must also have fail closed network filtering built in.
In summary, it's a QEMU VM orchestrator with a base OS image and project specific delta images. VM lifecycle is managed by systemd. System level isolation is already pretty good and it already solves the "AI wiped out my $HOME" problem. I'm currently working on a custom network stack to replace the nftables based firewall.
You want to prevent the agent/others from reaching your home directory and other things. As long as you don't mount/sync directories/files from/to the container, so no mounting like "-v $(pwd):/app", but instead copy in, then when done, copy out.
And of course, instead of doing the "copy in > copy out" process manually, get your local agent to write a bash script that does that for you, given what directory you're in, and you're basically G2G.
I wish they solved the issue happening for years on MacOS where Docker keeps up eating all available free space and ends up requiring restart of the whole machine, instead of Gordon and other useless shit.
The one thing I wonder about is how you enforce the usage of Docker Sandboxes vs running the agent on the host directly, apart from scanning machines for binaries
I used this for a while then decided to build my own suites that pack individual harness and respective host state (config, plugins, skills, etc.) into an image. Works better and much flexible in my opinion.
So essentially you can get latest Pi/Node pulling from that image:
`sbx run -t ghcr.io/shaftoe/sbx-template-pi:latest shell`
Like others here I'm also saddened by the login requirement but at the moment this is the best UX I could find for running sandboxed agents, the "kit/mixin" concepts are neat and I make use of them too: https://github.com/shaftoe/sbx-template-pi#stacking-the-extr...
Do the agents come preinstalled in the images? Or do they somehow use whatever I’ve installed locally? The former makes sense to me but then I’m wondering whether the sandbox images stay up to date with new releases of each image.
Ah let's see, do they still want you to LOGIN, in order to use a local dev tool? Yes, yes they do. No thanks Docker. You can keep your buzzword reasoning as to why this is needed.
TO me, that's the important distinction: sandboxing limits what the agent can do but it doesn't necessarily enforce that the agent must run inside the sandbox. You need a separate control layer to enforce that boundary.
You design the sandbox so the agent starts in that layer. The next thing you can do is to limit the network access, this is what I'm working on right now.
Not sure what you mean by "just". Containerisation is generally understood to mean something like what Docker does, which includes sandboxing but a whole lot more on top, like image management etc. Bubblewrap is just sandboxing without the rest of containerisation.
The login is annoying but, lacking an open source alternative, this has been my daily driver for a while now because it works great out of the box with two key features: outbound firewall and secret injection with placeholders.
I run it with superset and then each git worktree is mounted in a sandbox that is configured for each repo i work in.
Closest open source I have seen is https://earendil-works.github.io/gondolin but the DX is not as polished. https://exe.dev/ would be perfect but it does not come with outbound firewall.
Does anyone have a better alternative?
I use Linux Containers managed by Incus for working with Claude.
I have a dedicated container for that. It can run its own Docker daemon and other system services if needed.
Apart from the Claude login token, it has no SSH keys or other credentials. I push everything I need to it from the local machine. And I pull the Claude generated outputs from it.
Of course, this kind of setup requires a stack which can run or at least be tested without any credentials.
Don't want to say it's better, but I implemented Agent Circus (https://github.com/Embedded-Focus/agent-circus) which allows to lock AI agent harnesses into docker containers.
I'm using it as my main driver since months.
Support for running agent harnesses in unprivileged podman containers is on my feature list. :-)
Agreed. Network control and secret injection together with a microVM setup is as good as it gets right now, although I believe that we need more fine-grained tools down the road. It sounds like Microsandbox would be the perfect fit for what you are describing. I also built my own coding agent workbench on top of it (https://github.com/isolade/isolade). Microsandbox is quite cool, check it out: https://github.com/superradcompany/microsandbox
For persistent-ish one-off apps https://xbin.dev/ (my project)
Has egress and ingress filtering, egress can be bound to host/internet/subnet or even better to internal apps (which are each separate netns) meaning you can do your own firewall/vpn/whatever per sandbox. Plus you control what other components in the sandbox env the app can communicate with.
Really not built for day-to-day dev work though, more like automating your company/life / getting rid of SaaS (e.g. for technical Founders / Sales etc, not exactly useful for dev work)
Eclipse Enclave does exactly that: There is an outbound firewall and secret injections, so that the agent never sees a real key. And it's fully open source: https://github.com/eclipse-enclave/enclave
Looking at the Readme it seems like it only supports docker. Which is a dealbreaker for some
What is missing in qemu + podman that we need rootful docker for this? Is there actual capability that is missing or is it more of a design choice by the eclipse enclave folks?
If you just need a python+venv sandbox with dev-first UX, no container build step needed, and no startup cost then I am using https://github.com/nzjrs/sandbubble in prod.
maintainer, I would recommend trying out: https://github.com/smol-machines/smolvm
It has network filtering + placeholders for secrets.
OSS, no logins needed
I've put some effort to integrate it to my agentic workflow. The problem, however, with docker in smolvm: it work-ish (there is example), but quite hacky. Another problem which I wasnt able to solve - persistent image without Dockerfile. CloudInit will be ideal.
Documention at this moment in an early stage.
Overall, its a great project but for me was simpler just use Virtual Machine Manager (libvirt GUI).
I wish all luck to the maintainers, but probably DX-wise I will prefer to have more granular or predictable controls (eg micro cloud from Canonical).
ive been using https://github.com/Gerharddc/litterbox
I havent used nor gondolin neither docker's solution, but curious to know what gondolin is missing (evaluating both for my personal use)? is it only the DX or something else, if DX, can you what exactly is missing?
thanks
Yes, the stated "target workload"[0] is not what i'm looking for. I want my agent to run for long, spin up dedicated local stack while developing etc.
It seems with gondoling i need to explain the agent to run commands in the sandbox, but then where does the agent run itself?
[0]: https://earendil-works.github.io/gondolin/workloads/
You can run the agent in the gondolin sandbox if you wish.
Their example implementation with pi uses a pi extension so that pi runs on the host but the read/write/bash/etc tools run in the guest. Doesn’t have to be that way though.
https://github.com/e2b-dev/e2b
Does secret injection really prevent that the agent send my GitHub key somewhere? If it has access to it via env var, can it not just paste it somewhere?
The env var is just a placeholder in the VM, so no real secret is in there.
It’s injected into an outbound api call, not into an env var the agent can read.
or an outbound call to a trusted endpoint with the env var in a way that can get exposed to the agent via a subsequent call?
what's to stop an agent creating an outbound call with the var to a malicious endpoint? (unless you whitelist what it has access to)
What specifically do you want? I have:
https://github.com/pjlsergeant/byre -- slightly different security model, but lazer-focused on developer experience; my daily driver and I love it not just because I wrote it. The TUI is great for configuring and setting up instant boxes just how you want
https://pleasedonotescape.com/ -- a list of every other agent jail I could find, filterable by open-source and whatever else you want
What I run is one hardened QEMU/KVM VM per project holding the whole dev environment (editors, agents, containers), with nftables on the host allowing internet egress but dropping anything aimed at the host, the LAN, or any other private address, plus an allowlist for deliberate exceptions.
Basically, it's a plain QEMU/KVM VM on a stock Debian cloud image: device model stripped down to a virtio disk, a virtio NIC and a serial console, nested virt off, no passwordless sudo in the guest. It also ships a containment check that scans outward from inside the guest, so the network boundary is something you can verify.
Wrapping the whole environment rather than a single agent session puts supply chain attacks inside the boundary too. A poisoned npm or PyPI package, or a compromised editor extension, lands in the VM instead of on the host. That was the original reason I set this up; agents just made it more urgent.
There's no per-domain egress allowlist; the policy is "internet yes, private addresses no". Secret injection isn't built in either, though Infisical's agent-vault on the host as an egress proxy covers that part.
Wrote the whole setup up here, in case it's useful:
https://karamatli.com/posts/network-isolated-kvm-sandbox-ai-...
Apple Container is an interesting work in progress: https://github.com/apple/container
> Each agent runs inside a dedicated microVM with your dev environment
What's a "microVM" and what's the security model here compared to using real virtual machines with actual constraints on breakouts?
Is it marketing fluff?
Incus/LXD has had VM's for a long time now.
“microvms” are real vms but the hypervisor and vm (guest kernel) shed most of the hardware / device emulation, support, and discovery which makes traditional VMs look / feel like real computers, as well as most guest interactions. This gives them extremely low overhead.
Firecracker is designed to start a VM in under 125ms and 5MB. Netbsd advertises that you can direct-boot a MICROVM kernel configuration in under 10ms.
If an agent fires up NPM, takes a boatload of memory, is that memory released back to the OS after NPM shuts down in the VM?
In principle yes, in practice it's complicated, using something called "balloon drivers"
https://en.wikipedia.org/wiki/Memory_ballooning
There’s also memory hotplugging via virtio-mem. But generally speaking downscaling live vm memory can’t be said to be a solved problem, it’s more of an active area of research.
Your example is not complete, you have to show how it will run claude/codex, you have to do extra things to install run and mount folders there, this one does that with less config, also with this agents can run docker, lxd doesn't allow you to do that
There are many devs that have little to no experience of Linux, like the hundreds of thousands of .Net and Java CRUD devs in enterprise companies using Windows.
There is a need for a Docker desktop like GUI for this market.
When I was a teen I had no experience with software development. Then I went to school and learned about it. Now I'm making money doing this thing because I became quite good.
The world didn't fit around me, so I made "me" fit around "the world". I bet those stubborn dinosaurs can learn a new trick or two also, if management lets them do it during working ours...
Huh? https://docs.docker.com/desktop/setup/install/windows-instal...
Also, WSL (Windows Subsystem for Linux) has been baked into Windows for a long time and makes it very easy to play with Linux, as does using the Hyper-V VM system. Any developer unfamiliar with Linux because they use Windows, has little excuse.
It’s real VMs, firecracker style.
An Ubuntu Server VM, like the ones started by Incus, use at least 512 MB of RAM per instance. If you spawn 10 sandbox VMs, you already pay 5 GB RAM just to sit there idle. You also pay a CPU cost, you have 10 kernels managing stuff, but arguably it doesn't matter that much given CPU core counts.
I use something in between - a single Ubuntu VM, into which I spawn multiple Incus LXC containers for the agents. The containers only use 50 MB or so per instance (separate systemd, ...). This way I pay the VM RAM tax only once, and the agents are still contained inside the VM if they manage to escape the LXC containers.
That's a full VM. Microvms are much smaller and they start up very very fast. In miliseconds.
Wow, I hope one day Linux will be able to support the exclusive MacOs/Windows technology of Docker Sandboxes.
(it's in the doc, but kinda strange to not see some instructions on the main page, probably distro related)
There's always https://github.com/mensfeld/code-on-incus
What about bubblewrap? It also provides a sandbox
Yes, bubblewrap is superior to Docker for this. I wrote a tool to use bubblewrap for the purpose. It needs a tool to start it, or is at least much more convenient with a tool, because you need to take your session/auth data into the container, and if you want the agent to be able to start containers (agents love containers) within the container, you need some config magic mounted inside. You could manually do all that, or do it with a shell script, as well. But, this is how I did it, and you're likely to run into all the same little quirks I ran into:
https://github.com/swelljoe/flar
What is the main benefit over doing something like:
That runs the codex OCI in a qemu microvm. From what I can see, more fine grained network and filesystem access control as well as convenience?The credentials part...
https://docs.docker.com/ai/sandboxes/security/credentials/
It seems to do a good job of not stating the actual threat model anywhere.
I just made my own devcontainer that I copy on any project and load whatever harness I want in that repo. Harnesss' config and auth are simply mounted from the host, so no setup required at all.
https://github.com/iodize6399/ai-devcontainer/tree/main/.dev...
Yeah I also recently started using devcontainers for this
I quite like the 'features' layer system, adding extra tools to container in a declarative plugin-like way
Being able to 'safely' run with skip permissions has been a gamechanger
Does this support Linux yet? When I previously looked it did not (the reason being that they were already using VMs on Windows/macOS but not on Linux). Every time I see an announcement I think "great, they must've added Linux now then", but the linked pages always have Windows + macOS instructions but not Linux.
All the open GH issues about supporting Linux that I subscribed to have gone unresponded to.
OpenShell looks like a good alternative, but it still has "Do not use in production" plastered all over the website, which doesn't fill me with confidence yet
I think Linux has a better solution than Docker.
I wrote a tool to use `bubblewrap` to containerize any agent (at least all the agents I've used a couple of times), and bind mount the system stuff read-only, so the agent has your "usual" environment, but they can only see the project. Their history persists (either through a bind mount or a "shadow" copy of the history that only the wrapped agent sees), the agent can still create and manage containers of its own using podman's rootless mode, etc. It's nearly instant to start because it's just a namespace (plus a few copied files for the container support and session history); no container needs to be built/fetched/updated/whatever. bubblewrap is extremely well-tested as it is used by flatpak and several other large projects, so I trust it quite a bit (more than I trust Docker).
https://github.com/swelljoe/flar
I was able to install it on Fedora from the .rpm distributed on their GitHub releases: https://github.com/docker/sbx-releases/releases
I also hit the same issue recently. No Linux and no Windows on arm. AI sandboxing has a lot of options but none feel complete just yet. It's hard to commit to something, especially if reviewing tools to aide in company policies.
Regardless, I'm hoping something that isn't behind a login screen is going to win out.
It must be a joke that this tool is not supported on linux yet, although docker is built on top of linux containers. Shame on docker.
I got excited for this not because this didn't exist before, but because Docker putting their weight on this would imply a broader adoption and better integration in the industry. I am sad that they are asking for a login here though, which doesn't make any sense to me.
That's docker, man. Tomorrow they're gonna add limits on sandbox runs without a premium account too
microVMs (firecracker) have existed for years. This is not new.
I started building my own isolated and security-hardened docker image for OpenCode about half a year ago. Been using it daily.
https://github.com/pkhamre/opencode-docker
if I was paranoid about security I wouldn't use docker in the first place.
Models start going to extreme, damaging lengths to achieve ambiguous prompts[0]. Having good sandboxes is now a must IMO.
But sbx is a bit annoying to use with OpenCode for instance (which has zero sandboxing by default, unlike codex CLI or Claude Code). You cannot easily change ~/.config/opencode/opencode.jsonc AFAIK.
[0]: Black Hat OpenAI-Hugging Face incident: https://www.youtube.com/watch?v=87DyyMV0kCY&t=1021s
That incident was with a model that had the guardrails disabled.
Still obviously you should run all untrusted code in a sandbox, but extreme actions like that would be very unusual with the model that shipped.
Requires login. Garbage.
I build a OSS lightweight, portable VM for those that don't want lock ins: https://github.com/smol-machines/smolvm
I have a solution based on Nix that can be used to generate reproducible container images: https://github.com/nothingnesses/agent-images . It lets you customise which agents, harnesses, or any other packages you want included in the VM and it uses `agent-box` for sandboxing.
wonderful, will try to test this in smol machines as well
This looks like gvisor but is a vm like firecracker right? Any reason you did not want to use firecracker?
(I am testing this now as a backend for my pet project which currently supports firecracker and gvisor. No network.)
It's a batteries included alternative to firecracker with a couple of new ideas tossed into the mix i.e. portable like a container (bake into a single file and rehydrate the vm anywhere), dynamic resource allocation, etc.
What? Does using sbx require login? Bummer.
Yes and they have a specific subscription for managing sandbox policies across the enterprise: Docker AI Governance
You can create those manually but if you want to enforce those then you need the subscription
If any AI company was doing serious engineering isolated containers would have been a prerequisite to using their tools.
Anyone serious about security will want to bring their own sandbox anyway, not trust these, often proprietary, agents. I've never run an agent outside a sandbox. My first bubblewrap script for `claude` is now over a year old. The tools are available and if you learn to use them you can run any program in a sandbox.
But, in any case, why put in effort doing something people don't expect or ask for? We can assume everyone running agents is either a) using their own sandbox, or b) doesn't care. I think we can guess which category most people fall into. You could maybe argue about responsibility, but I don't think you can argue about "serious engineering".
> Anyone serious about security will want to bring their own sandbox anyway
Exactly. It's not as though it's difficult. It never occurred to me to not do this from day one, and it astonishes me that anyone runs this stuff bare metal. Since then, I've brought several other people on board, and that's all they've ever seen: I don't think they'd know how to run outside a sandbox, and that's just fine.
Reminds me of sandboxy - https://github.com/apple/containerization/tree/main/examples...
Also if your thing doesn't work with `pi` out of the box, then low effort
The other day I saw this: https://nono.sh/
Haven't tested it yet, but it seems to address the same issue as Docker Sandboxes, but in a different way.
I have tested it and the big advantage is that is has access to the local development tools.
But it’s not as well sandboxed for sure.
Why do you say that?
Eg, if used with Colima in macOS, it means I can run a devcontainer in an isolated VM and Nono inside the devcontainer can restrict a lot what can and cannot be done.
You get credentials proxying and network outbound limits.
How is Docker Sandbox better sandboxed?
Before you use no sandbox at all use this or one the many similar projects but it's alway worth remembering that Docker is not a security boundary. It never has been meant to be and never will become one.
cgroups are a mechanism designed for hierarchical organization and resource distribution. Against a malicious and capable actor, and that is how we have to treat AI agents, cgroups will not withstand.
Also, the kernal is an interface too big for what an AI agent needs and is therefore offering a gigantic attack surface completely unnecessarily.
Would you say podman is better, or is it the same as docker ?
In general running containers rootless is better from a security standpoint and podman makes this much easier. So, yes.
This is not my main point though. Both are based on cgroups and cgroups are the wrong tool for the job.
Wouldn't it need a super critical exploit, I mean zero-day vulnerability, to escape from that kind of sandbox ? And if you think further, then isn't that risk also applicable to pretty much any kind of sandboxing ?
Container escapes are more common than you think. Common enough for AWS not to rely on containers for their serverless functions, common enough for Google to say: "Untrusted code shouldn't rely on the container security boundary [..]" [1]
The same is not applicable for any kind of sandboxing for two reasons:
1. The boundary is in the kernal’s own code, enforced by the thing you are trying to be protected from. -> Use a VM
2. The kernal is a gigantic attack surface -> Use gVisor
[1] https://docs.cloud.google.com/kubernetes-engine/docs/resourc...
What if you use tools like bubblewrap or nono inside the container?
Say I want to use pi inside a container. If I wrap pi within a bubblewrap or within nono, how is that less secure than using a vm?
Also, I think most people run containers inside VMs anyway and not directly on their hosts (on Mac and windows you have to use a vm anyway).
Can someone more versed in Docker explain to me how this is different than building my own docker container from a Dockerfile for using Pi agent harness? That's what I do currently. I use Docker Desktop in windows as the backend for that.
Docker containers use Linux kernel features to create an isolated environment, running on the same machine as docker is. This creates a virtual machine, with its own kernel, and runs the container in there. This gives stronger isolation and security guarantees.
I have the same question as GP. Your answer helps a little but not really. I might be naive, but I was under the impression that malicious code escaping a docker image and running amok on my host system was not something I should be too worried about. Especially if I run docker in rootless mode. Is that wrong?
For clarity I’m actually using podman, not Docker.
Oh no, you should definitely be worried about that. Podman might make it harder to escalate to host root, or manipulate other containers, but it is still vulnerable.
Now I'm curious to know how hardened the Docket Sandbox orchestration interface is. I guess we can assume they have run Mythos against it for a few weeks maybe? It's unclear.
Unsettling. I mean, is there any reasonable way to develop software in 2026? I've already sworn off ever installing npm directly on my host. Containerizing everything is laborious enough, but running a separate VM for everything?
You just need to work out the threat model for what you're working on. For trusted containerized workloads, where the attack surface is minimal, just containerization is fine. However, agents can do just about anything on your computer if you allow it and people aren't really shying away from `--dangerously-skip-permissions`, so better hardening (VMs, microVMs) is desirable.
BS.
Unless we're talking 0-day/CVE, running an unprivileged container is as trustable as a VM. The only difference is how strictly you want to hold the memory/CPU bar. Infact on linux, containers are more lightweight than VMs.
So yeah, not "vulnerable".
When the host is a Mac or window , docker always run in a VM anyway.
On Linux, you can run docker directly on the host, but you can also very easily setup a vm with incus and run docker from there.
That depends on the runtime though. For example, libkrun lets you do this:
That starts/runs the OCI in a qemu microvm.It's a VM.
I know some people want to run their agents when their computer is off, but I imagine a solution like this will be much more common than paying for a remote sandbox (i.e on fly.io or exe.dev), especially because it'll be free.
Though, they need to remove the login requirement.
The sandboxing problem is perhaps the greatest justification for doing agent integration via existing human interfaces rather than low level shell access. Granting access to shell is a super obvious path (it's easy) so I can understand us wanting to fight for it. But we should consider the other paths as well before we make our final stand.
Automating browsers with LLM agents properly requires a lot more work than Process.Start into powershell, but the advantages can be immense once you have achieved integration this way. Incrementally maintaining this integration is generally easy because human users cannot tolerate rapid changes either.
It's a hell of a lot easier to convince management to adopt a robot that looks and acts like a human employee than one that looks like a combine harvester. The combine is far more efficient, but it is also totally indiscriminate. Nothing constrains its appetite except for the invisible fence imposed by GPS. The amount of infrastructure required to keep farm equipment from running astray is incredible. In the context of agriculture, the added complexity is definitely worth it. We don't want to have to recreate the same thing with our technology if it can be avoided. Sandboxes and security isolation boundaries are not things to aspire to. These are costs to be paid for admission to something more valuable.
I tried Docker Sandboxes but last time I checked you could not configure custom volume mounts, making more complex setups impossible. For work I need two directories for context for the agent to have access to…
put them both inside another directory and share that? what am i missing?
Open source alternative with podman support and local telemetry collection https://github.com/VibePod/vibepod-cli
Looks really nice. Would it be easy to make a qwen-cli wrapper?
I'm confused: 1. If I run this on Mac, then inside the sandbox / microVM, am I still running MacOS or some Linux distribution? 2. If the only thing that's mounted from the host is the $PWD, how does it guarantee that it has all the system libraries that I have installed on my host system? e.g. my `/opt/homebrew` libraries or `sudo apt install libfoo-dev` headers
I did try to use those for some stuff: * Login requirement is something else * It's closed source last I checked * Pretty slow/unstable
There are many better namespace/container based options, VMs may be moderately more secure but when you more or less trust your agent and code you can do with lesser containment. And with the recent CVEs in kvm honestly there isn't a huge deal of difference vs namespaces.
(I'm building https://xbin.dev/ for some time now for managing my personal code/apps, a project which started specifically after Docker Sandboxes broke on me some time ago)
I’d rather use another open source solution that doesn’t require a signup, and less likely to get rugpulled.
There is no reason to require a login for creating local mini sandboxes.
If you’re on Apple, native solutions like “container-machine init” come built in and are pretty good, if you’ll only be on Apple hardware.
I wrote a CLI tool that uses QEMU's microvm machine type under the hood. It can take any docker image and build a microvm.
I use it regularly to run Claude/Codex with permission checks disabled.
https://github.com/cvhariharan/mvm
I use it (sbx), but I don't 100% trust that it actually works, and I would prefer something open source where the limits of the sandboxing could be tested and explored.
Maybe we should just ssh into separate development machines to ensure real and verifiable sandboxing? (as was totally standard before Docker became a thing)
You should research bubblewrap and nono.
I hardly see how this matters, when Apple and Microsoft already have their own in box solutions for the same problem.
Better sandboxing for AI agents is exactly the main reason for containers improvements on macOS and Windows, with a few talks at WWDC, and BUILD.
Not sure how much they would get from Linux users then.
I've been keeping a list of all the agent sandbox providers if you're looking for alternatives to this
https://engine.build/lab/agent-sandboxes
The open source section specifically.
Most interesting part to me is credentials injection at the sandbox boundary level: https://docs.docker.com/ai/sandboxes/security/credentials
Doesn't everyone do this now? It's hardly a new idea. Yet every time someone proposes the idea, people fawn over it and proclaim it the best thing ever.
Yes, you can inject tokens via a proxy. What else is new?
Who is doing it as first class feature with at least adequate UX?
I have skimmed alternatives offered in comments to this post (vibepod-cli, code-on-incus, opencode-docker, sandboxy, smolvm, amazing-sandbox) and none of them seem to do credentials injection at the proxy level.
nono.
Also fnox now does credentials proxying.
Just a small meta note: most of the comments in this thread appear to be posting their own codebase (typically AI-generated) that accomplishes the same goal. It's interesting that this problem is simultaneously in high demand and yet considered trivial enough to vibe code per-user solutions to it.
Like many people, I suspect, I used Claude to write my own agent sandbox that suits my needs very well. Investing my time in a propietary product has become a hard sell.
I did the same thing. It was my first "vibecoded" project. I've been using it every day and it's great. I'm writing a custom Rust network stack for it right now. Gonna replace the current nftables firewall with it.
As for Docker Sandboxes, I'll just ask Sol literally right now to see what it does better than my virtdev, and then I'll improve virtdev instead of using Docker.
Were you following any patterns/standards/advice on what you needed to protect against? Anything you can point the rest of us to?
> Were you following any patterns/standards/advice on what you needed to protect against?
Just the general knowledge that sharing a kernel with untrusted software is too dangerous, that hardware virtualization is an infinitely smaller attack surface and that the entire industry will be in deep shit if people or AI breaks hypervisors.
Initial threat model was supply chain attacks but eventually grew to include AI harnesses as well. Not very worried about them hacking me, more about accident prevention.
So that means each VM must be running a completely independent kernel that's fully isolated from the host's file system. They must also have fail closed network filtering built in.
> Anything you can point the rest of us to?
I have published my virtdev's design document.
https://github.com/matheusmoreira/virtdev/blob/master/DESIGN...
Yes, it is AI generated.
In summary, it's a QEMU VM orchestrator with a base OS image and project specific delta images. VM lifecycle is managed by systemd. System level isolation is already pretty good and it already solves the "AI wiped out my $HOME" problem. I'm currently working on a custom network stack to replace the nftables based firewall.
You want to prevent the agent/others from reaching your home directory and other things. As long as you don't mount/sync directories/files from/to the container, so no mounting like "-v $(pwd):/app", but instead copy in, then when done, copy out.
And of course, instead of doing the "copy in > copy out" process manually, get your local agent to write a bash script that does that for you, given what directory you're in, and you're basically G2G.
What is the advantage of copying rather than a bind-mount?
What specifically are you looking for? If you start from the premise that it runs as you right now, then that's something you can easily improve upon.
Start by mounting just your repo and passing in the keys for the agent. Take it from there, it's like software engineering, you iterate.
When you run into issues you expand the tools in the container available to it.
Why developers will never pay for their tools.
I wish they solved the issue happening for years on MacOS where Docker keeps up eating all available free space and ends up requiring restart of the whole machine, instead of Gordon and other useless shit.
The one thing I wonder about is how you enforce the usage of Docker Sandboxes vs running the agent on the host directly, apart from scanning machines for binaries
I used this for a while then decided to build my own suites that pack individual harness and respective host state (config, plugins, skills, etc.) into an image. Works better and much flexible in my opinion.
Has anyone started proving their sandboxes in Lean (or Coq, etc.)?
So this is a VM by Docker?
For those who do not trust
AND do not want to use some other, free VM for some reason?Better yet, use Apple's container CLI if you're on a Mac, instead of the docker bloatware.
container run --rm -it -v "$(pwd)":/work -w /work myaiimage /bin/bash
Hasn't Docker always been just a thin layer of duct tape over existing solutions?
Has anyone tried https://bhatti.sh/ ?
I am not sure I understand, how is this different from a devcontainer or other similar techniques?
On another topic, can't help but notice that "leading coding agents" somehow does not include Pi.
About the missing native support for Pi, I opened this issue long ago in case you want to add some pressure: https://github.com/docker/sbx-releases/issues/34
To work around that limitation I came up with this https://github.com/shaftoe/sbx-template-pi
So essentially you can get latest Pi/Node pulling from that image:
`sbx run -t ghcr.io/shaftoe/sbx-template-pi:latest shell`
Like others here I'm also saddened by the login requirement but at the moment this is the best UX I could find for running sandboxed agents, the "kit/mixin" concepts are neat and I make use of them too: https://github.com/shaftoe/sbx-template-pi#stacking-the-extr...
it's running a full VM so the agent can eg: run docker commands safely etc
been using this for a while - works great! Has also had a lot of updates over the past year so worth checking out again if you tried it a while ago
Do the agents come preinstalled in the images? Or do they somehow use whatever I’ve installed locally? The former makes sense to me but then I’m wondering whether the sandbox images stay up to date with new releases of each image.
The agent is per installed. If there is an update to the agent, the VM notifies you on a first run and updates it if you approve.
Other than the login problem, it’s a decent option.
Ah let's see, do they still want you to LOGIN, in order to use a local dev tool? Yes, yes they do. No thanks Docker. You can keep your buzzword reasoning as to why this is needed.
Here's another sandbox that I found interesting: https://github.com/ashishb/amazing-sandbox
Very interesting. Thanks for sharing.
So it's basically a container with a fancy name, innit?
TO me, that's the important distinction: sandboxing limits what the agent can do but it doesn't necessarily enforce that the agent must run inside the sandbox. You need a separate control layer to enforce that boundary.
You design the sandbox so the agent starts in that layer. The next thing you can do is to limit the network access, this is what I'm working on right now.
Or do you mean something else?
On Linux, you can skip Docker and use bubblewrap. Some inspiration: https://blog.gpkb.org/posts/ai-agent-sandbox/
Bubble wrap is just containerisation no?
Not sure what you mean by "just". Containerisation is generally understood to mean something like what Docker does, which includes sandboxing but a whole lot more on top, like image management etc. Bubblewrap is just sandboxing without the rest of containerisation.
Docker Sandboxes is using microVMs, not containerization.
...or...just hear me out now...we could limit it in the harness.
Don't give it shell access, just predefined tools.
What if it puts malicious code into test file and you allow `npm run test `?
The linked page implies there is no linux support, I wonder why. It's there in the docs if you hunt for it.
The docs are here: https://docs.docker.com/ai/sandboxes/
The other url is their marketing page.
Yes, Linux is supported.
Docker management will fail their tech at every opportunity.