I was very excited to hear about Docker Sandbox. It sounded like it solved a problem that I and others have had for a while, and where the solution historically has been “switch to Podman”. Unfortunately, once I tried to dig in and actually use Docker Sandbox I learned that it appears to only work with a hardcoded list of AI agents that are supported by Docker.
Why was it designed like this? It feels like there is no reason why this couldn’t work with any docker-compose file, or any arbitrary orchestration image.
Is it too late to generalize the solution to work with any docker container, as a drop-in solution to any container that wants privileged: true or docker.sock access? While one of the uses for this is certainly AI stuff, and that is one of the places I would like to use this, I would really like to see it expanded to be a more general purpose tool rather than hitching on the open-claw bandwagon and ignoring the broader set of use cases.
Docker Sandbox is still an experimental feature and you can expect it evolving soon, but even now you can use your own template and if you use the “shell” type, you can use any app in it, including your custom AI agent.
Sandboxes are based on Micro VMs containing their own docker engine. That means you can run multiple containers in this sandbox. The AI agent can run containers as well to test something. If you need, you could allow the agent to access the Docker Daemon’s TCP socket on the host.
I could imagine using a sandbox as a Docker container runtime, but the sandbox supports network policies as well, not just running a container. The sandbox has to limit access to your LAN network and there are some other deny and allow policies by default.
If you have feature requests, I think you can share it in the roadmap
I didn’t know about the shell sandbox, that perhaps is a bit closer to what I was hoping for, though it appears to contain far more than I would expect in a simple shell image, coming in at ~1.3GB and includes many tools I have no use for (e.g., python, go, Node.js).
I just looked at https://docs.docker.com/ai/sandboxes/templates/ and it says to use FROM docker/sandbox-templates:claude-code which definitely doesn’t feel like a clean base image that I’m used to for docker stuff. I would want something like FROM docker/sandbox-templates:alpine or similar. Not only does the claude-code sandbox come with tools I don’t want inside my sandbox, it appears to be ~1.5GB, which is absolutely massive for a base docker image!
The sandbox also does some additional things like proxying certain requests that are very specific to AIs. This also could be generalized to support an arbitrary proxy container that can proxy anything the user wants, and the user can choose to use the Claude proxy (or not).
Overall I’m frustrated because docker sandboxes does exactly the thing I want, but it adds a bunch of seemingly unnecessary features on top that aren’t opt in. It feels like the exact same set of features could have been implemented without the tight coupling to AI agents and it would have served both the AI agent crowd and everyone else.
I’ll try to turn some of this into concrete feedback and file it over at the repository you linked. I hope that Docker can get back to its roots and building foundational tooling rather than trying to jump on the AI bandwagon. We need good foundational tooling for AI stuff, and Docker is well positioned to build that, but trying to build the whole stack monolithically is going to end up with much worse foundational tooling that doesn’t fit people’s needs as they change.
The agent images for the container part of sandboxes provide a base to run an agemt/assistant and mcp servers for most people. The images are implemented to work with the sandbox mechanism. The balance between ease of use and security is the primary objective. Like @rimelek already wrote: it’s an experimental feature, so nothing is set in stone,
It is an example, you could have also used FROM docker/sandbox-templates:shell as base. That’s what you would end up using, if you don’t want to use one of the existing agents images.
It is a forced http(s) proxy. You can managee it using docker sandbox network proxy <sandbox> [OPTIONS]. This also follows the ease of use objective. You can lock it down as much as want/need. Running other containers (mcp servers?) in the sandbox vm is not covered by ease of use yet: it needs to use the http(s) proxy and https traffic requires --bypass-host <domain>:<port> to make outgoing traffic work.
Much appreciated! It is a quick moving topic, and its always good for Docker to know how their tooling is used in a way that deviates from the opinionated implementation is was created for and how things can be done better.