microsoft / microsoft/vscode-remote-release

Allow VSCode-wide security configuration.

Open
#11,428 0 comments 5 reactions 1 assignee View on GitHub

@chrmarti is already working on this.

Since Jan 14, 2026.

containers
Dominant language
Dockerfile
Stars
4.2k
Forks
469
Avg merge
1d 1h
Merged PRs (30d)
1

Description

TL;DR: Allow users to disallow .devcontainer files from taking certain actions.

Currently, using Dev Containers in any repository where you don't monitor the full changelog is dangerous. This comes from the fact that a malicious .devcontainer file can result in total system compromise. It can do this in a few ways ranging from mounting the entire host filesystem inside the container, having a malicious initializeCommand, or running a container with --privileged.

Dev containers, if properly protected, can give users a very significant security sandbox to work in, allowing them to work with third party codebases without having to worry so much about their whole system being compromised if someone slipped in something sneaky.

Small Request:
Add configuration options (settings.json) that allow the user to disable certain features. While a full security audit would be valuable, at the very least it should allow disabling the usage of --privileged, disallowing mounting of any volumes outside the current directory, and disabling the initializeCommand script entirely.

Bigger Request:
Even better would be if it could be made so that the there is an option to enable, disable, or prompt when these features are utilized. This way, a user could still leverage those features for repositories they personally maintain, but could avoid having them covertly used by malicious repositories.

At the moment, users wanting to use dev containers essentially need to load the folder in VSCode untrusted mode, fully audit .devcontainer, and then open it in a remote container in trusted mode. A middle ground would go a long way to making things far safer, with what seems like a fairly minor change to the extension.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.