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?

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

    incus launch images:ubuntu/26.04 my-ubuntu-vm --vm
    incus exec my-ubuntu-vm -- bash

I tried it and it worked great at first but I had multiple issues with it, the disk space usage was growing significantly, I need to login multiple times for each sandbox, it's closed source and not possible to customize to my need.

One other thing, I want to be able to handle multiple repos in the same sandbox and have a standard workflow around worktrees (one worktree per repo, all the worktree mounted in the VM).

These were some of the reasons that led me to build: Clawk - https://github.com/clawkwork/clawk

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)

What is the main benefit over doing something like:

    docker run --runtime krun --rm -it -v $(pwd):/workspace/$(basename $(pwd)) -w /workspace/$(basename $(pwd)) --network restricted-net ghcr.io/openai/codex-universal:latest sh

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?

Apple Container is an interesting work in progress: https://github.com/apple/container

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

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.

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

Are we sandboxing AI agent harness process, or the environment it executes commands in?

Ideally, they should run in _different_ sandboxes.

The environment might corrode the harness (e.g. rogue npm/pip packet would manipulate agent harness config).

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

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.

If any AI company was doing serious engineering isolated containers would have been a prerequisite to using their tools.

Requires login. Garbage.

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

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

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.

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.

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…

Open source alternative with podman support and local telemetry collection https://github.com/VibePod/vibepod-cli

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)

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

Most interesting part to me is credentials injection at the sandbox boundary level: https://docs.docker.com/ai/sandboxes/security/credentials

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.

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

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.

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 this is a VM by Docker?

For those who do not trust

    docker run --rm -it -v "$(pwd)":/work -w /work myaiimage /bin/bash

AND do not want to use some other, free VM for some reason?

Has anyone started proving their sandboxes in Lean (or Coq, etc.)?

Has anyone tried https://bhatti.sh/ ?

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

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.

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.

Here's another sandbox that I found interesting: https://github.com/ashishb/amazing-sandbox

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.

On Linux, you can skip Docker and use bubblewrap. Some inspiration: https://blog.gpkb.org/posts/ai-agent-sandbox/

...or...just hear me out now...we could limit it in the harness.

Don't give it shell access, just predefined tools.

The linked page implies there is no linux support, I wonder why. It's there in the docs if you hunt for it.

Docker management will fail their tech at every opportunity.

[flagged]

[flagged]

[dead]

[dead]

[dead]

[dead]