Docker posted a new product page for Docker Sandboxes, a tool for running coding agents like Claude or Codex inside short-lived environments with mounted project files, outbound network controls, and proxy-based secret injection. The big architectural clarification came from Docker itself: despite the branding, this is not ordinary container isolation. Each sandbox is a microVM with its own kernel, running on the host platform’s native hypervisor through a new Docker-built VMM. That mattered because much of the conversation started from the usual “Docker is not a security boundary” objection, then shifted once people realized Docker was really selling VM-grade isolation wrapped in a Docker-style workflow.
What people actually liked was straightforward. A lot of developers now treat agent tooling as untrusted code execution and want something safer than bind-mounting a repo into a container. The strongest practical features called out were
deny-by-default egress, host-bound secret injection so API tokens stay outside the guest, and the ability to let agents run Docker inside the sandbox without handing them the host. Several commenters said Sandboxes already works well as a daily driver, especially when paired with git worktrees and terminal presets.
The louder reaction was frustration with product choices, not the core idea. Requiring a Docker login for a local sandbox tool was the single biggest complaint by far. People read that as future lock-in, enterprise upsell pressure, or a sign that local policy enforcement will end up gated behind subscriptions. Closed source status made that worse. A second source of confusion was platform support. The launch page initially looked Mac and Windows only, which triggered a pile-on about Docker somehow shipping an agent sandbox without obvious Linux support. Docker employees clarified that Ubuntu support already existed, Fedora worked from the
RPM, and the marketing page was simply wrong and later fixed.
Once the basics were sorted out, the conversation settled on tradeoffs between full VM isolation and more composable host-native approaches. MicroVMs were treated as the current sweet spot when you want real containment without the weight of a traditional VM. At the same time, many experienced users said a single hardened VM per project, or one VM containing multiple containers, is often the more realistic operating point because it avoids the memory tax of one full guest per agent while still keeping the host out of reach. Others argued that
bubblewrap, Nono,
rootless Podman,
Incus, or Apple’s container stack are good enough when the threat model is narrower and you care more about instant startup and reuse of existing dev tools.
The thread also exposed how fragmented this category still is. Instead of a clear consensus alternative, there was a flood of personal tools and early open source projects offering some mix of microVMs, container wrappers,
egress filtering,
worktree management, and secret brokering. That cut two ways. It showed the demand is real and the pattern is becoming standard. It also showed nobody has locked up the space yet. Docker’s advantage is packaging a messy stack into a usable default. Its weakness is that the audience most likely to care about sandboxing is also unusually allergic to forced accounts, opaque security claims, and proprietary control planes.
docker.com