GitHub Copilot: Remote Dev Container Agent Sessions in VS Code
GitHub CopilotVS Code 1.139 lets GitHub Copilot's Agents window run an agent session inside a project's Dev Container hosted remotely, over SSH, a Remote Tunnel, or WSL, not just on a local machine. The Agent Host now runs inside the remote container while the Agents window itself stays on the developer's machine, giving the agent the exact tools and dependencies the remote project defines instead of a mismatched local toolchain. It extends the local-only Dev Container support GitHub Copilot shipped in VS Code 1.138 the previous week, and Docker must be available on the remote host for it to work. The capability is rolling out gradually behind the chat.agentHost.devContainer.enabled setting, so it may not be on by default yet for every developer.
Key Takeaways
- GitHub Copilot's Agents window can now run a session inside a remote Dev Container, reached over SSH, Remote Tunnels, or WSL, not just a local one.
- The Agent Host runs inside the container on the remote host while the Agents window stays local, keeping the agent's tools in sync with the project's actual environment.
- The feature requires a supported Dev Container configuration in the project and Docker installed on the remote host.
- It's enabled through the
chat.agentHost.devContainer.enabledsetting and activated via a "Use Dev Container" action in the folder menu. - It directly extends the local-only Dev Container support GitHub Copilot shipped just one week earlier in VS Code 1.138.
- The rollout is gradual, so developers may need to manually enable the setting to try it before it becomes default.
Sources & Mentions
2 external resources covering this update
From Local-Only to Remote Dev Containers
A week after GitHub Copilot's Agents window gained the ability to run a session inside a project's local Dev Container, VS Code 1.139 extends that same capability to projects hosted remotely, over SSH, Remote Tunnels, and Windows Subsystem for Linux (WSL). Previously, a developer working on a remote or WSL-hosted project who wanted an agent to build and test inside that project's Dev Container had no direct path to do so from the Agents window; the agent either ran against the remote host's raw environment or required a developer to duplicate toolchain setup elsewhere.
How It Works
For a remote Dev Container session, the Agent Host itself runs inside the container on the remote or WSL host, while the Agents window interface stays on the developer's own machine exactly as before. This split means an agent gets access to the container's tools, language servers, and dependencies as defined by the project, without the developer needing to replicate that setup locally or directly on the bare remote host. It removes a common source of drift between what an agent can do and what a human developer's own environment supports, since both now draw from the same containerized definition.
Setup and Requirements
Developers turn the feature on with the chat.agentHost.devContainer.enabled setting, then select "Use Dev Container" from the folder menu inside the Agents window. Two requirements apply: the remote or WSL-hosted folder needs a supported Dev Container configuration already checked into the project, and Docker must be installed and available on the remote host itself, since that is where the container actually runs.
Rollout
GitHub is rolling the capability out gradually, so the setting may not appear enabled by default for every developer yet, mirroring how the local-only version of this feature shipped the week before. Developers who want to try it ahead of general availability can turn the setting on manually. The feature is aimed squarely at teams whose day-to-day development already happens on remote infrastructure, whether through cloud workstations reached via SSH, VS Code's own Remote Tunnels, or WSL on Windows, giving them the same agent-in-a-container guarantees that local-folder users got first.