hi, I'm just curious if nobody else here was ever alarmed by how there is no way to configure OpenHands locally without giving it any form of a system access to our machine. Just to promote my question & doc suggestion, I'll link the https://openhands-ai.slack.com/archives/C06U8UTKSAD/p1774895726914329

I’m using docker sandboxes and finding them quite suitable for agent long-horizon workflows. It lets you run docker commands inside, with its own daemon and full isolation from the host docker. https://docs.docker.com/ai/sandboxes/

thanks, that looks interesting. Do you have an example of a complete setup solution though? It seems the docker container and the sandbox are two concepts with different lifecycles, so we need to properly configure the whitelists while also being able to keep it configured as a standalone container. Also, reading about the automagically configured defaults such as a shared Git user name makes me worried how safe the defaults are, but I guess we won't find any safer alternative than the sandbox. Its microVMs are probably safer than standard DinD, and this both isolates the Docker daemon and also allows network policies such as "Locked Down".

I'd love to get the docs updated on the options that are available for Docker. I think this page we have is one of our lowest rated from feedback https://docs.openhands.dev/openhands/usage/advanced/custom-sandbox-guide Did you get any further with the docker config @wonderful-airport-43031? If anyone else has made progress here it would be great to get help updating the doc or even a fresh one for the ai sandboxes.

@hundreds-twilight-32833 nah, I've only started reading articles about docker sandbox, so I'd appreciate if the examples could be provided by anyone who has tested them properly. (Though tbh, sadly, security is more a matter of analyzing risks than the matter of "testing". One layer of virtualization is the bare minimum, but not necessarily optimal.) Btw. so far I've only learned that the

sbx

has to be explicitly installed, which seems kinda dangerous considering it's around beta release version

0.2

, but on the other hand, the

docker sandbox

alias/alternative is pre-installed with Docker Desktop, so that one seems more comfortable to use 🙂 The

custom-sandbox-guide

article sounds as if it only talks about a specific sandbox that a specific agent uses, i.e., once we have OpenHands running in a separate Docker container (as illustrated by the documented

docker run

command where the

docker.sock

is just as dangerous here as in the original Setup article). Honestly, I'm still new here and don't know how those GUIs and Agents can be "connected to each other" etc. Docker Desktop's GUI has recently also started introducing various AI tool integrations, so I wonder how long it'll take before a tool such as OpenHands can also become a first-class citizen there. (Even Docker Sandbox already has agents like OpenCode preconfigured as per https://docs.docker.com/ai/sandboxes/agents/ ). Specifically, I'm currently exploring how their "MCP Toolkit" seems to provide a plug-and-play solution to integrate MCP servers (and clients?), but I'm new in this field, and your (OpenHand's) documentation regarding MCP is also severely lacking. I'm looking for a well-defined and portable solution to introduce similar databases and tools for agents to use, but I still don't know where and how to optimally install them. For example, I'd like to see a Markdown (Obsidian)-based knowledge base where AI can contribute, but not necessarily overwrite my approved documents, while also letting AI maintain its own graph database for thinking around my documents before persisting new updates (or suggesting an upstream PR with changes).

I’ve been using the new docker sandboxes for a few weeks now and about a week ago I noticed that docker moved all their docs from

docker sandbox

to the

sbx

cli, so I guess

docker sandbox

will not continue and

sbx

is their preferred solution in the space. There are a few interesting design decisions in the transition.

docker sandbox

worked with local template images and required no auth.

sbx

requires authentication and custom templates have to be published in a registry. This makes them harder to use but I'm sticking to the preferred method going forward. Also,

docker sandbox

mapped localhost internally seamlessly but

sbx

requires

host.docker.internal

, which is more familiar coming from normal container workflows. Simple containers don't offer network isolation which is key, so they won't do for a secure setup IMHO. I find these sandboxes a bit tedious to set up and they surely take system resources and are a bit slow to create and manage, but there's no way we can leave long-running agents unattended in host systems, so sandboxes it is. I'm working on a coding harness in this repo and I have added a custom template with support for openhands and claude code. It's rough and I'm still working on it. I'd love to know your feedback. https://github.com/atineoSE/ola

Thanks for sharing the interesting details; it makes me sad how complex the Docker's current state of affair is. I'm looking for some all-in-one solution that isn't hard to understand and provides well-defined guarantees / permissions API, but I guess there's no way to avoid having to internalize brand new conceptual models of both the sbx and docker sandbox tools. I agree that they seem to be the best choices today, though it doesn't make them any easier to learn to use. After all, we're just one typo away from accidentally executing a tool outside the sandbox 😕 In any case, your

ola

tool seems quite well-designed; if only I had the time to delve into its inner workings to be able to set up similar scripts on my own, its usage patterns would be very useful. I still need to learn the basics of integration of today's AI tools though, without being able to dedicate any time specifically on experimentation.

Totally understand. I'm not too knowledgable on docker myself so hoping to get some extra help in documenting+finding a solution. I'd love to get a config available that address the need and makes it easy to run

Thanks for the feedback, @wonderful-airport-43031 and 100% agree on having to internalize these concepts. I thought this exercise would be setup-and-go and… I’m already 3 weeks in and not fully done 😅 I still think these are important new idioms for the new paradigm in programming. If agents do the coding, then I guess the engineers’s work is to manage the agent and sandboxes seem an unescapable new skill. Based on your feedback I have added a new check to avoid running my sample harness outside of the sandbox accidentally. It now checks for a specific env var and, if missing, requires a dangerously looking new flag. This is similar in spirit to the

--dangerously-skip-permissions

of claude code or

--yolo

of openhands. Mind you, it’s the first trick everybody learns 😂 (as verified in a local community meeting a couple of weeks ago)