The agent can enter the project environment.
VS Code 1.138 adds local Dev Container sessions to the Agents window. When a local folder has a supported Dev Container configuration, the workspace picker can offer "Use Dev Container." The agent then works with the tools and dependencies defined for that project. Docker must be installed, and Microsoft says the feature is rolling out gradually.[1]
This solves a real failure mode. A coding agent that runs on the host may see a different compiler, runtime, package manager, or system library than the project. Moving the session into the same declared environment cuts that mismatch.
A workbench file can carry authority.
The Dev Container specification defines more than an image. A devcontainer.json can forward ports, set container and tool environment variables, choose users, add mounts, request capabilities, and set a security option. It can also run lifecycle commands such as postCreateCommand and postStartCommand.[2]
Those controls make the environment useful. They also mean the file is executable workstation policy. Review a changed Dev Container definition with the same attention you give a build script.
Environment parity answers "Can it build?" Boundary review answers "What can it touch?"
The workspace may still be a host mount.
VS Code documents two common file paths. Workspace files can be mounted from the local filesystem, or they can be copied or cloned into a container volume. Extensions run inside the container and have access to its tools and filesystem.[3]
That distinction matters. A bind-mounted repository can give a process inside the container direct write access to host files in the mounted path. An isolated volume changes that relationship, but it does not decide network access, credentials, or the power of any mounted control socket.
Docker draws the first line, not the last one.
Docker describes namespaces as the first form of container isolation and control groups as resource accounting and limiting. Its security guide also warns that daemon control is powerful. Docker can mount host directories into a container, and access to the daemon can permit host-level changes. The guide recommends restricting daemon control to trusted users.[4]
The practical rule is simple. "Runs in a container" is an implementation fact. A security claim needs the configuration and a test receipt.
Pin four things before launch.
- Image: pin the base image or digest, inspect Features, and record the rebuild command.
- Mounts: list every bind mount, volume, socket, and forwarded port. Mark each path read-only or writable.
- Network: state whether egress is open. Name allowed destinations if the task needs a narrow route.
- Authority: identify the container user, capabilities, secrets, SSH forwarding, and Docker socket access.
Now the Dev Container does two jobs without pretending they are one. It provides the project toolchain, and it carries a reviewable boundary contract.