-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Description
Description
Hi, not 100% sure this is the right place, but #6734 and the sandbox docs is why I thought it might be relevant for the docker team.
Running a devcontainer inside a Docker Sandbox seems like a much cleaner path to safe AI agent workflows than building per-tool CLI integrations.
The concern: with VS Code devcontainers on top of WSL2, a typical devcontainer runs against your normal Docker Desktop daemon. Host paths are accessible, the Docker socket is often exposed, and mcr.microsoft.com/devcontainers/python ships with passwordless sudo (I'd assume other mcr.microsoft.com/devcontainers images do too). Concretely, inside a devcontainer with the Docker socket exposed and passwordless sudo, I can trivially mount /mnt/c. That's just one example.
Docker Sandboxes already solve the isolation side of this by running in a dedicated micro VM with only the project workspace mounted. So why not just run the entire devcontainer inside the sandbox? VS Code has a command palette option called "Dev Containers: Clone Repository in Container Volume" which copies the workspace into a volume rather than bind-mounting host storage. That pattern combined with sandbox isolation feels like a natural fit.
Would this be worth discussing here, or should I open an issue in devcontainers/cli?