Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Docker Sandboxes – Disposable, isolated sandboxes for AI agents

docker.com

Post reply on HN
Print view View original

361–370 of 440 posts

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#361

Post by isityettime »

speedgoose wrote: post #291
LeBit wrote: post #148

Earlier quoted context omitted.

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?

Yeah but that’s Colima and Nono then. Not only Nono.

True. But it's also an illustration of how relying on an OS' native sandboxing capabilities is nicely composable with other isolation techniques.

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#362

Post by mikesir87 »

roywiggins wrote: post #354
messh wrote: post #308

Earlier quoted context omitted.

Couldn't the agent post then the key in some public comment?

Only if the replacement is global and not, say, only looking and inserting it into the actual (eg) Authorization header. If something is only transparently altering the Authorization header, then an agent inserting the dummy value somewhere else is totally safe.

For clarity, there is no "search and replace" function going on. It's only setting the header.

The main reason a "proxy-managed" env var is set is because most CLI tools assume if the env var is set, auth is set. If the env var is unset, it will assume auth needs to occur. Fortunately, most don't do a pattern matching on what the value actually is.

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#363

Post by binsquare »

icedchai wrote: post #237
binsquare wrote: post #98

Earlier quoted context omitted.

maintainer, I would recommend trying out: https://github.com/smol-machines/smolvm It has network filtering + placeholders for secrets. OSS, no logins needed

There's also microsandbox which has similar features: https://github.com/superradcompany/microsandbox (Not affiliated with them, just tried it out last week.)

I'm aware of them!

Yep - similar in some ways but headed towards different directions.

I am building a virtual machine to simplify/replace container infra. Ex. we run containers inside of linux VM's even in the `cloud`, resulting in managing both the vm, and the containers.

But smol machines is a lightweight, portable VM that you can package into a single portable .smolmachine file to be rehydrated on any platform, kind of like how containers are used for today.

Sandboxing happens to be a feature of virtual machines, so we are alike in being used for sandboxing.

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#365

Post by geoka9 »

everforward wrote: post #277
mikedelfino wrote: post #273

Since everyone is sharing their setup, here’s my approach, just to give people an idea of how others are doing it, however impractical it might look: I run a full Linux VM (with a GUI) on my Linux host. I connect via virt-viewer to run Claude Desktop, as I’m not a fan of using the terminal for this. The VM sits on its own libvirt network in a dedicated firewall zone, and specific directories are shared via filesystem…

Do you find the permanence of a full VM useful? I’ve wondered about something like this but always defaulted to Docker for much the same reasons people use stuff like Ansible. I’m afraid the LLM will heavily customize its environment and I’ll be unable to replicate it when my laptop dies or I can’t upgrade the OS or whatever. Then again, I guess GUI is a pain in Docker. I tend to operate through Zed and an ACP harnes…

My understanding is that the OP is not running any heavy tools/chains inside the sandbox? I use a similar setup, but using Incus and cli agents which I drive via ssh. I make sure I can (and do) rebuild the VM from scratch after every session or so.

Currently considering using ACP for codex so that I can do more of the driving from my editor (emacs, over ssh) and something similar for claude code (it doesn't seem to be as good as codex at supporting re-attachable sessions).

One concern is making sure my editor's ACP client doesn't enable/support fancy terminal stuff, because that would basically void all the benefits of using a VM sandbox.

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#366

Post by android_reverse »

srini-docker wrote: post #298

I work at Docker. Lot of valid and useful feedback here that we're looking closely at. One correction: this isn't containers. Each session is a microVM with its own kernel on the platform's native hypervisor: Hypervisor.framework, WHP, KVM. We wrote a new VMM (not Firecracker) to make it more effective across platforms. Explained a bit more here about the architecture and why those choices were made: https://www.dock…

VM? own kernel? I wonder if this could allow to run Waydroid on Windows without the hassle of recompiling WSL kernel with Binder and Docker

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#368

Post by esafak »

sylvinus wrote: post #213
rusch wrote: post #58

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/gondol…

Are we all posting our agent VM containers ? :) https://github.com/sylvinus/agent-vm

What is different about yours?

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#370

Post by rusch »

notsirius wrote: post #302
rusch wrote: post #58

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/gondol…

Ooh - can you share more about your setup with superset? I tried getting it integrated with superset a while ago with no dice.

Currently running codex. I run one sandbox per repo. So I create the sandbox in the repo root. Then it's a custom terminal preset:

sbx run --name "yoursandbox" -- --cd "$PWD"

This boots a sbx session in the worktree directory.

For Claude there is no --cd so it's more hacky, but I solved it by creating a sbx kit with entrypoint script that reads a flag (e.g --cwd) from the terminal preset command and then inside the sandbox cd's there and starts claude.

Post reply on HN