VS Code Dev Containers
containerdev-environmentopen sourceA Docker container as your whole dev environment, real reproducibility and process separation, but a convenience boundary, not a hard one.
Dev Containers turn a Docker container into your whole development environment, described by a committed devcontainer.json, so agents and tools running inside are scoped to it and your team gets a reproducible setup. The verdict: it is a convenience with real process/filesystem separation, not a hard security boundary, it shares the host kernel, the workspace is usually a bind mount of real host files, and common configs (root, --privileged, a mounted Docker socket) make escape trivial. is open by default; harden with non-root, dropped caps, no-new-privileges, a socket proxy, and isolated volumes.
Strengths
- Reproducible, committed dev environment from devcontainer.json
- Real process/filesystem separation and ecosystem support
- Remote editing keeps files in the container while the editor UI runs on the host
Limitations
- A convenience boundary, not a hard one: shared kernel, and the workspace is usually a bind mount of real host files
- Trivially escapable if run privileged, as root, or with the docker socket mounted
- Egress open by default, must be locked down separately
Files & editor
desktop-mountThe canonical desktop-editor flow: VS Code attaches to the container and edits your bind-mounted project.
How you get your project into the environment and edit it. Shared-kernel routes bind-mount host files for your desktop editor; own-kernel routes keep files in the guest, so a desktop editor attaches over remote, or you edit inside. Mounts and remote editing.