Updated 28 Sep 2026: VS Code 1.139 materially extends the Agent Host/Dev Container story from local projects to remote SSH, Tunnel and WSL hosts, and adds a central session catalogue for large persistent-agent histories.
VS Code’s Agent Host can now run Dev Container sessions on remote SSH, Tunnel and WSL projects
VS Code 1.139 extends its persistent Agent Host again: Dev Container agent sessions can now run against projects on SSH, Tunnel and WSL hosts, so the agent can inherit the remote project’s containerized toolchain instead of requiring that environment on the developer’s laptop.
Agent Host Dev Container sessions now support projects on SSH, Tunnel and WSL hosts.
Docker must be available on the remote host and the project needs a supported Dev Container configuration.
The feature is still rolling out gradually and may need to be enabled manually.
Microsoft also changed session-list metadata storage to reduce the cost of loading large persistent-agent histories.
What builders should take away
If your coding environment already lives on a remote workstation or VM, test whether the Agent Host can now use that project’s Dev Container instead of recreating the toolchain locally.
Review what credentials, sockets, mounts and Docker privileges become visible inside the remote Dev Container before treating unattended agent sessions as routine infrastructure.
Keep rollout assumptions conservative: Microsoft still describes remote Dev Container sessions as gradually rolling out.
What changed
Visual Studio Code 1.139 extends the Dev Container support introduced in 1.138 from local folders to projects reached through Remote SSH, Tunnels and WSL. The remote folder needs a supported Dev Container configuration and Docker on the remote host. Microsoft says the feature is still rolling out gradually and can be enabled manually with chat.agentHost.devContainer.enabled.
Why it matters
This removes another local-machine assumption from persistent coding-agent work. Teams can keep the project, dependencies and execution environment on a remote development host while the Agent Host runs the session inside that project’s Dev Container. That makes the architecture more useful for larger repositories, remote workstations and controlled development environments, while shifting credential, Docker and host-mount review to the remote machine.
Dev Container sessions now follow remote projects
VS Code 1.138 let Agent Host sessions run inside a local project’s Dev Container. Version 1.139 extends that path to projects opened over SSH, VS Code Tunnels and WSL. The remote folder must contain a supported Dev Container configuration and Docker must be available on the remote host.
The session catalogue is also being optimized for persistence
VS Code 1.139 changes how the Agent Host lists large numbers of sessions, keeping lightweight session and chat metadata in a central catalogue instead of opening every conversation database. Microsoft reports about 12x faster first listing and 4x faster refresh in a development-machine test with roughly 645 sessions; those are vendor-produced measurements and smaller histories should see less benefit.
What to watch next
Whether remote Dev Container Agent Host support becomes enabled by default and leaves preview/gradual rollout status.
Whether AHP clients beyond VS Code gain the same remote-container execution path.
How enterprise policy and credential controls evolve for long-running remote sessions.
Still unclear
Microsoft does not yet present remote Dev Container Agent Host sessions as universally enabled for every user.
The published session-list performance numbers are Microsoft measurements from a development machine with roughly 645 sessions and should not be treated as general benchmarks.
The important failure is not another prompt injection. Plugin4Shell breaks the mechanism intended to guarantee that an AI-agent plugin is still the exact code a marketplace reviewed.
The important shift is that agent orchestration itself becomes a managed API surface: context compaction, tool discovery, programmatic tool calls and subagent coordination can now come from OpenAI’s maintained Codex harness rather than an application team rebuilding those layers.
Codex 0.149.0 includes the async-message tool, delivery metadata and removal of the client-side feature gate that BTN previously tracked only on main. Parallel human-agent work is now in a stable client, but late replies can still race with decisions and model capability metadata remains the final exposure gate.