Flag any devcontainer.json entry that widens what the container can do: privileged, capAdd, securityOpt, mounts, runArgs, initializeCommand, and Features that add the same. Each is a legitimate setting with a clear purpose, and each deserves a written reason in the pull request.
Why dev container files need review
A devcontainer.json file lives in the repository and tells tooling how to build and run your development environment. A change to it can change the privileges of every developer who opens the project. Yet many teams review application code closely and wave through a few lines of container settings.
The review table
| Setting | What the reference says | Why to flag it |
|---|---|---|
| privileged | Runs the container in privileged mode, required for things like Docker in Docker, with security implications particularly when running directly on Linux | Broad access to the host |
| capAdd | Adds capabilities typically disabled, often SYS_PTRACE for debuggers | Each capability widens what a process can do |
| securityOpt | Sets security options, with seccomp unconfined as the example | Can turn off syscall filtering |
| mounts | Adds mounts using the same values as the Docker mount flag | Can expose host folders |
| runArgs | Passes arbitrary Docker command line arguments | Can carry any of the above |
| initializeCommand | Runs on the host machine | Executes outside the container |
| features | Adds Feature installs to the container | Feature metadata can add privileges and run install scripts as root |
| containerUser and remoteUser | Default is often root | Everything runs with root powers inside the container |
All descriptions come from the containers.dev reference. The "why to flag" column is this post's guidance.
The classic debugger request
The reference itself shows a common case: to let ptrace based debuggers for C++, Go and Rust work, add the SYS_PTRACE capability. It also gives an example of unconfined seccomp for the same purpose. These are reasonable asks for a native debugging project and unnecessary for a web front end. A reviewer can ask a simple question: does this project debug native code in the container? If not, remove the lines.
What a good pull request note looks like
For each flagged setting, ask the author to state:
- What breaks without it.
- Whether a narrower option exists, such as one capability instead of privileged.
- Who owns the exception and when it will be revisited.
Automating part of the check
Search every devcontainer.json for the names in the table in CI, and fail the build when a new hit has no linked reason. A short allowlist file with an owner and a date per exception keeps the list honest. See the lifecycle commands guide for the host side command and how Features change container settings for the install side.
What review cannot catch
A clean file does not make the image safe. Base images and tools added during setup bring their own packages and vulnerabilities. A container is also not described by the specification as a boundary against hostile code, so open unfamiliar repositories with the caution described in the extension trust post.
Safeguard's dependency and image scanning covers what the dev container installs, with a free scan at gold.safeguard.sh/scan.
Quick check
Is privileged mode ever justified in a dev container?
The reference says it is required for things like Docker in Docker. If the project needs that, record why and prefer a rootless alternative where it works.
Who should approve changes to this file?
Someone responsible for developer environment security, in addition to the code owner, since the file changes privileges for everyone who opens the project.
Sources
Last reviewed: 19 October 2026.
