Docker Sandboxes – Disposable, isolated sandboxes for AI agents (docker.com)

Just put the following to your `.config/sandboxy/agents/pi.json`

{ "allowedHosts": [ ".anthropic.com", ".claude.com", ".pi.dev", "npm.org", ".npmjs.org", ".github.com", ".githubusercontent.com", ".pypi.org", ".pythonhosted.org" ], "baseImage": "docker.io\/library\/node:22", "displayName": "Pi", "environmentVariables": [ "IS_SANDBOX=1" ], "installCommands": [ "npm install -g --ignore-scripts @earendil-works/pi-coding-agent", "npm install -g global-agent" ], "launchCommand": [ "pi" ], "mounts": [ { "containerPath": "\/root\/.pi", "hostPath": "~\/.pi", "readOnly": false } ] }⏎

Why developers will never pay for their tools.

This is not really an alternative if you care about the security of your host system. Docker Sandbox uses micro VMs for a reasons.

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

Agreed! I think the best user experience is:

    1. You can run sandboxes locally
    2. You can control them securely over the internet, for when you're on the go
    3. You can migrate them to cloud VMs if you want

If I can toot my own horn, I'm trying to build that :)

Still early and the local sandboxes are experimental right now

https://github.com/gofixpoint/amika

When starting a sandbox, you can specify the mountpoints you want. It just defaults to the current directory. You can also specify some of those mounts as read-only as well.

Example: sbx run claude ./ ../another-project:ro

This was added recently https://docs.docker.com/ai/sandboxes/usage/#multiple-workspa... ` sbx run claude ~/project-a ~/shared-libs:ro ~/docs:ro`

if I was paranoid about security I wouldn't use docker in the first place.

[dead]

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

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.

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

Whoah. I took for granted it'd work on Linux.