How to Use Dev Containers with AI Agents in VS Code (Without Giving It Your Entire Laptop)

AI Dev Tools — General
, , , , ,
1

VS Code can now run an AI agent session within your project’s Dev Container: the agent compiles, tests and installs with your project’s tools, not what you have on your machine. It arrived with VS Code 1.138 (September 16, 2026), starts with the Use Dev Container action in the Agents window and requires Docker.

Status as of September 21, 2026: VS Code documentation marks the feature as experimental and the setting that controls it comes disabled by default. The release notes indicate it’s being rolled out gradually, so you might not have it active yet; you can enable it manually (see below). The Agents window, the only place where it works, is in Preview.

Why run an AI agent inside a Dev Container?

Because an agent running on your machine uses your Node, your Python, your compilers and your global packages, and it does so with your user’s permissions. That creates two problems.

The first is environment drift. How well the agent “works” is only as good as its environment: if your machine has Node 22 and the project pins Node 20, the agent can pass tests that your CI will reject.

The second is scope. VS Code’s own sandboxing documentation warns that the agent’s terminal commands can execute processes with the same operating system permissions as your user account.

A Dev Container solves the first one outright: the environment is defined in the repository, it’s the same for everyone on the team, and the agent inherits it. It also helps with the second, though not completely; the security section below explains the limits.

What is a Dev Container and what goes in devcontainer.json?

A Dev Container is a Docker container described by a devcontainer.json file inside your project, which tells VS Code what image, tools and runtimes your development environment should have. The format is an open specification (containers.dev), so it doesn’t lock you into VS Code.

The configuration goes in .devcontainer/devcontainer.json, or in .devcontainer.json at your project root. The minimal example from VS Code’s documentation simply points to a precompiled image:

{
  "image": "mcr.microsoft.com/devcontainers/go:1"
}

You don’t need to write it by hand. The Dev Containers extension (ms-vscode-remote.remote-containers) includes the Dev Containers: Add Dev Container Configuration Files… command, which generates the file from a template, an existing Dockerfile, or a Docker Compose file.

If you’re not yet working with containers in your daily routine, at yoDEV we have a previous guide on consistent development environments with Docker.

How do you use Dev Containers with AI agents in VS Code?

You need Docker running, a Dev Container configuration in the folder, and a setting enabled.

1. Check the requirements. Docker installed and running, with the Docker CLI available in the PATH. The local folder must contain .devcontainer/devcontainer.json or .devcontainer.json.

2. Enable the setting. Open Settings, search for chat.agentHost.devContainer.enabled and enable it. It’s an application setting, not a workspace setting.

3. Open the Agents window. You have three options:

  • Click Open in Agents in the title bar.
  • Run Chat: Open Agents window from the command palette.
  • Run code --agents from a terminal.

4. Start a session inside the container.

  1. Select New.
  2. In the workspace selector, expand the menu for your folder and choose Use Dev Container. The workspace label gets the suffix “- Dev Container” added.
  3. If you change your mind before starting, choose Use Local from the same menu.
  4. Choose a harness, configure the session, and write your prompt.

From then on, the Agent Host (the process that runs the agent) runs inside the container, while the Agents window stays on your machine. According to the Agent Host documentation, file edits and commands run in the environment that hosts the agent.

Why doesn’t the “Use Dev Container” option appear?

The four most likely causes are:

  • The setting is not enabled. Due to gradual rollout, it might still be off in your installation.
  • The folder doesn’t have a compatible Dev Container configuration.
  • Docker is not running, or its CLI is not in the PATH.
  • You’re in the regular chat view. The action only exists in the Agents window.

If the container fails to start, open the Output panel and select the Dev Container channel for your workspace: that’s where the configuration and connection logs are.

Does it work with Claude and Codex, or only with Copilot?

The Agent Host is designed for multiple harnesses: its documentation shows adapters for Copilot, Claude, and Codex. The steps for Dev Containers just indicate that you choose an available harness.

As of September 21, 2026, the documentation doesn’t detail which harnesses are confirmed inside a container, so test yours before relying on it.

Does it work on Windows?

Yes, through Docker Desktop:

  • Windows 10 Pro/Enterprise: Docker Desktop 2.0 or higher.
  • Windows 10 Home: Docker Desktop 2.3 or higher with WSL 2 backend.
  • Linux: Docker CE/EE 18.06 or higher. The Docker snap package on Ubuntu is not supported.

Two things don’t work on Windows: Windows container images and Docker Toolbox.

What are the limitations?

  • No worktrees. A Dev Container session works directly on the container’s workspace and can’t be combined with New Worktree. You lose the pattern of “letting the agent work on an isolated copy of the branch”.
  • Single folder only. The Agents window doesn’t yet support multi-root sessions.
  • Experimental status. Behavior and settings may change between versions.

Is a Dev Container a sandbox for the agent?

Grego’s take:

It’s a real boundary, but don’t confuse it with a vault. I’d use this feature, and at the same time be clear with my team about what it provides and what it doesn’t.

What it provides. Microsoft’s own sandboxing documentation ranks Dev Containers above terminal sandbox, which is lighter: it clarifies that terminal sandboxing doesn’t replace the isolation offered by cloud sessions or Dev Containers. The agent’s commands run against the container’s file system and tools, not your home directory, global packages, or other projects.

What it doesn’t provide.

  • Your project files are still exposed. A local folder opened in a Dev Container is normally mounted from your disk (bind mount), so the agent’s edits can reach your actual files. Combined with the lack of a worktree option, a bad turn by the agent edits your checkout, not a copy.
  • Your credentials can travel with you. The Dev Containers documentation indicates that if you use a Git credential manager, the container probably already has access to it. It’s a convenience for you, and it’s also access for the agent.
  • The network isn’t restricted. Nothing in the Dev Container configuration limits outbound traffic. VS Code’s terminal sandbox has its own controls for that, like chat.agent.sandbox.allowNetwork and a list of allowed domains. They’re separate layers, and you can use both.

My recommendation for teams: make the Dev Container the default place where agents run, because reproducibility alone justifies it. Commit before each agent session and treat the container’s isolation as one layer, not your entire security model. We developed the broader pattern in Code Agents Need Sandboxing — Not Just Good Prompts and in Containment-First Agents, and we cover Microsoft’s bet on isolating agents at the operating system level in Microsoft’s Sandbox for AI Agents Reaches the Kernel.

What else does VS Code 1.138 bring for agents and Codex?

  • Codex in VS Code, expanded. Codex in the Agent Host can now use a GitHub Copilot or ChatGPT subscription, and you can switch between models without losing the conversation. Sessions can move from the ChatGPT app to VS Code, and Codex can use VS Code’s built-in tools, extensions, and MCP. The settings are chat.agentHost.codexAgent.enabled and chat.editor.codex.preferAgentHost.
  • Pull requests from agent sessions. A single form lets you edit the generated title and description, mark the PR as a draft, and choose merge options. The Agent Merge option is experimental and depends on chat.agentMerge.enabled.
  • Session cleanup (Preview). Sessions whose pull requests have already been merged can be marked as completed automatically and, if you want, deleted after a grace period. It’s disabled by default.