In VS Code Dev Containers, UI extensions such as themes stay local and most other extensions install and run inside the container. You gain a repeatable environment and trust prompts, but the documentation does not describe the container as a security boundary for untrusted code, so do not assume it is one.
What a dev container is
The Dev Containers extension lets you use a container as a full development environment. A devcontainer.json file, at .devcontainer/devcontainer.json or .devcontainer.json in the project root, tells VS Code how to access or create the container. It can name an image, a Dockerfile or a Compose file, forwarded ports, extensions to install, and post create commands.
Where extensions run
Per the documentation:
- Extensions that affect the UI, such as themes and snippets, install locally.
- Most other extensions install and run inside the container, with access to its tools and file system.
You can list extensions in devcontainer.json, set always installed extensions with dev.containers.defaultExtensions, or opt out of one a base image configures by prefixing its ID with a minus sign. Note that Settings Sync does not synchronize extensions to or from dev containers.
Trust prompts you will see
The Dev Containers extension follows Workspace Trust. You are asked to trust:
- A local or WSL folder before reopening it in a container.
- An existing container when you attach, once.
- A repository when you clone it into a volume, once.
Inspecting a volume opens in Restricted Mode. Using a remote Docker daemon implies trusting the machine that runs it. Codespaces and attached containers are trusted automatically, per the Workspace Trust page.
What reaches the container
Two things deserve attention:
- Files. If you bind mount a local folder, the container sees it. A repository container using a Docker volume keeps your local file tree clean.
- Credentials. If you clone using a Git credential manager, the container can usually access those credentials. SSH keys can be shared if you opt in.
So a container holding untrusted code with your credentials mounted is not isolated from them.
What this means for safety
A dev container is an environment definition. It keeps tool versions consistent and keeps tools off your host. The documentation does not claim it contains a hostile repository. Treat the devcontainer file as code that runs commands: read postCreateCommand and the image source before trusting a repository. See the checklist for unfamiliar repositories.
Good practice
- Pin base images and review Dockerfiles.
- Do not mount more of the host than you need.
- Keep credentials out of the container unless the task needs them.
- Use separate containers for untrusted work.
Teams and consistency
The real value for teams is consistency. Everyone gets the same compilers, the same linters and the same extension set, listed in one reviewed file. That makes audits easier, because the extension list is in version control and changes show up in pull requests. It also means that changes to devcontainer.json deserve review like any build script.
Mistakes to avoid
Do not mount your whole home directory into a container for convenience. Do not forward credentials you do not need. Do not assume that a container started from a stranger's configuration is harmless because it is a container.
Quick check
Does a dev container sandbox a malicious repository?
The documentation does not present it as a security boundary. Treat it as a convenience, and limit what you mount and share.
Sources
Last reviewed: 19 October 2026.
