September 22, 2026: VS Code agents are gaining local Dev Container sessions, allowing them to work with a project’s configured tools and dependencies. The feature appears in VS Code 1.138, released September 16, and was highlighted in GitHub’s September 18 Copilot update.
What changed
In the Agents window, a session can now use a local folder’s Dev Container instead of the host machine’s toolchain. Docker must be installed, and the folder needs a supported Dev Container configuration. Availability is rolling out gradually.
The release notes identify chat.agentHost.devContainer.enabled as the relevant setting. When enabled, eligible folders expose a Use Dev Container menu action. Users can enable the setting manually if it is not yet on by default.
For context, Microsoft’s Dev Containers documentation explains that a project’s devcontainer.json defines how VS Code accesses or creates its development environment, including its tool and runtime stack.
Why this matters for QA engineers
Our QA assessment: this could reduce environment mismatches when an AI agent investigates a failing test. A project-defined runtime gives reviewers a clearer starting point than an undocumented collection of tools on one developer’s laptop. It does not establish that the environment matches CI or that generated tests are correct.
For an initial evaluation, ask the agent to reproduce one known failure in the container. Record the runtime and dependency versions, exact test command, exit status, and output. Run the same check in CI and compare results before accepting a proposed fix. Browser tests also need their browser binaries, system libraries, and test data checked explicitly.
What to watch: whether your repository’s configuration is supported and whether its container reliably reproduces CI failures. Those checks will determine the practical value of this rollout for your test suite.