VS Code 1.139 Adds Agent Dev Containers on SSH, WSL and Tunnels

VS Code 1.139 Carries Agent Dev Container Sessions to SSH, Tunnel and WSL Hosts​

Microsoft's release notes describe the main change in one sentence. Version 1.139 lets agents build and test a remote project with the right tools and dependencies, "without duplicating toolchain setup on your laptop or the remote host." In practice, when you point an agent session at a folder on an SSH server, a VS Code Tunnel or a WSL distribution, the agent can now work inside the container that the project's Dev Container configuration defines. It no longer depends on whatever happens to be installed on the host.

Independent coverage agrees on the scope. NT Compatible and Warp2Search both report that this update also extends Dev Container support to remote SSH, Tunnel, and WSL hosts, allowing agents to build and test projects efficiently without duplicating setups. Neowin's first report on the release describes it the same way.

The change is narrower than a headline like "remote Dev Containers" suggests. VS Code's long-standing Dev Containers and remote development extensions already let people work inside containers on remote machines. Version 1.139 adds the same ability for agent sessions in the Agents Window, the separate agent workspace that runs on VS Code's agent host. Microsoft describes that host as a dedicated process built on the Agent Host Protocol (AHP), which lets several VS Code windows connect to the same session. If you never open the Agents Window, this feature does nothing for your normal remote-development workflow.

Community trackers of the Insiders builds show how the work arrived. One tracker summarizing pull request #336249 reported that it adds Agents Window support for running Dev Containers when the source is over SSH or Tunnel hosts. WSL support followed in a separate change, #336573. According to the same tracker, that change extends Dev Container support to WSL folders by running the Dev Container CLI on the selected WSL host and adding smoke coverage for real agent session flows. That detail explains the Docker requirement described below: the container is built and run on the machine where the code lives, not on your laptop.

Turning On Use Dev Container in the Agents Window​

Microsoft documents a short setup, and each prerequisite is a real gate. Three conditions have to be met:

• The chat.agentHost.devContainer.enabled setting must be on. Microsoft marks it "Agents Window only."
• The remote folder must contain a supported Dev Container configuration.
• Docker must be available on the remote host itself (the SSH server, tunnel machine or WSL distribution), not only on your local PC.

Once those are in place, the procedure is:

1. Update to VS Code 1.139 by choosing Check for Updates in VS Code, or download the Stable build.
2. Open Settings, search for chat.agentHost.devContainer.enabled and turn it on.
3. Open the Agents Window and select a project folder on an SSH, Tunnel or WSL host.
4. Open that folder's menu and choose Use Dev Container. The agent session will then run inside the project's container.

If Use Dev Container doesn't appear, check the three prerequisites first. The most likely cause is that the setting is still off, because Microsoft says in the 1.139 notes that Dev Container sessions "are rolling out gradually, so the setting might not be enabled by default for you yet," and that you can enable it manually to try the feature now. NT Compatible reported the same caveat: this is rolling out gradually, so you may need to flip the setting yourself. The next most likely causes are a folder without a supported Dev Container configuration, or a remote host without Docker.

Microsoft's release notes don't list which Dev Container configurations count as "supported," and they don't explain what happens if the container build fails on the remote host. If your team uses unusual devcontainer setups, try one project before relying on the feature.

One Week From Local Folders to Remote Hosts: The 1.138 Baseline​

Remote support comes quickly. VS Code 1.138, released on September 16, 2026, introduced agent sessions in local Dev Containers using the same chat.agentHost.devContainer.enabled setting. In that release, local folders with a supported Dev Container configuration showed a Use Dev Container action in their folder menu, and Docker had to be installed on your own machine. The same gradual-rollout note applied.

Version 1.139 keeps the local behavior and the setting, and it changes where the container can run:

For Windows developers the WSL piece is the practical one. Many Windows users keep Linux toolchains in a WSL distribution and don't want them duplicated on the Windows side. With 1.139, an agent working on a WSL folder can use a container on that WSL host, which is presumably where the project's Docker setup already lives. That fits the release notes' stated aim of avoiding toolchain duplication, but the WSL-specific benefit is our inference and not a claim Microsoft makes.

A Central Catalog Makes Large Agent Session Lists Load up to 12x Faster​

The second headline change mostly helps heavy agent users. According to Microsoft, the agent host used to open every conversation database each time it built the session list, so the work grew with the number of sessions you had. Now the host keeps lightweight session and chat metadata in a central catalog and builds the list from that. Full conversation content stays in the individual session and chat databases. NT Compatible summarized the result as full conversation content stays isolated in the individual session and chat databases, so data boundaries hold.

Microsoft published before-and-after timings measured on a development machine with about 645 sessions:

These are Microsoft's own figures from one machine. A verification bot reviewing a Machine Herald article on the release noted that the two flagged performance multipliers (12x/4x session-list load times) and the Dev Container local-to-remote (SSH/Tunnel/WSL) claim are Microsoft's own stated figures/wording. That confirms the numbers were quoted accurately. It doesn't mean anyone reproduced them. Microsoft itself says users with few sessions should expect a smaller difference, which follows from the design: removing per-session work helps most when there are many sessions.

No action is needed to get the speedup. Microsoft says sessions created before 1.139 are migrated to the new catalog automatically in the background.

Compact View, Inline Rename and Chat Tabs Tidy the Agents Window​

Beyond the speed work, the Agents Window gets several organizational changes. Neowin's count of "three new key features" leaves most of these out.

Compact View, turned on from the sessions list view, fits more sessions on screen. A compact row shows only the session title until you hover over or focus it, then reveals workspace details. A row expands when its session needs input or approval, so those requests don't get hidden. Progress shows on the row of the chat doing the work, and a collapsed session's parent row summarizes progress from its hidden chats.

Disable Empty Groups, found under Filter Sessions, hides empty custom groups and the empty Chats section. Microsoft says the preference is stored in your profile and resets along with the other session-list filters.

Inline renaming lets you rename a session or a nested chat directly in the list. You can double-click the title, choose Rename from the context menu, or focus the row and press F2. Blank titles are rejected, and cancelling restores the old name. A 1.139 Insiders build tracked earlier in the cycle also added F2 support for renaming the active session header, plus a chat tab presentation menu (Single vs Multiple) in the header overflow.

That menu ships as a Preview setting, sessions.showChatTabs, and it too is limited to the Agents Window. An agent session can hold several chats, each a separate conversation or context. Multiple shows each chat on its own tab. Single shows only the active chat and hides the tab bar. Microsoft says switching modes keeps your open chats, your active chat and the conversation state. In Single mode, chats you explicitly open to the side stay as separate panes with their own header actions.

Word Wrap Indicators and Bracket Auto-Closing Fix Everyday Editor Friction​

Two changes affect everyone who uses the editor, whether or not they touch agents.

Word wrap indicators mark soft-wrapped lines with an arrow at the wrap column on the right side of the editor. This helps anywhere a long line visually splits into what look like several lines: configuration files, Markdown and long string literals. The Stable release notes call this "display word wrap indicators" but don't name a setting on the release page. The Insiders notes refer to it as editor.wordWrapIndicator, so if you don't see arrows after updating, check Settings for that entry rather than assuming the indicator is on by default.

Bracket auto-closing now avoids inserting a duplicate closing bracket when you type an opening one. If a matching closing bracket already exists, VS Code uses it. If not, it inserts one. This targets the familiar case of editing inside existing code and ending up with a stray extra ) or }.

The release also includes a proposed extension API, which is not yet part of the stable API surface. It adds an optional expiresAfter property to AuthenticationSession that reports an access token's remaining lifetime in milliseconds. It uses a remaining duration rather than an absolute timestamp because the extension host can run on a different machine from the client, and the two clocks can disagree. Microsoft says its built-in Microsoft account authentication provider already supplies the value. Extension authors who pass credentials to SDKs with their own refresh logic are the audience for this.

Enterprise Fixes Close an Agents Window Policy Bypass​

Two items in the notable-fixes list matter more to IT administrators than any of the headline features.

The first applies to organizations that disable Agent mode through account policy. Microsoft says 1.139 hides the Agents Window welcome invitation for those users and stops alternative launch paths, including code --agents, from getting around the control (issue #336968). If your organization blocks Agent mode, earlier builds may have let a determined user open the disabled Agents Window through those paths. Getting fleets onto 1.139 closes that gap.

The second fixes a race condition in how enterprise-managed OpenTelemetry (OTel) settings were applied to the local agent harness, the non-Agent Host path in the Copilot extension. Microsoft says the fix ensures those OTel settings are no longer dropped (issue #336701). Teams that collect agent telemetry through managed OTel settings should expect more reliable collection after updating.

What This Means for You​

Most users can simply take 1.139 as a routine update. People who run agents against remote or containerized code have a reason to install it now and turn on the Dev Container setting. Admins who enforce Agent mode policy should prioritize rolling it out.

• VS Code 1.139 reached Stable on September 23, 2026, for Windows x64 and Arm64, macOS and Linux. Use Check for Updates to get it immediately rather than waiting for the automatic offer.
• Agent sessions can now run inside a project's Dev Container on SSH, Tunnel and WSL hosts. This requires chat.agentHost.devContainer.enabled, a supported Dev Container configuration in the remote folder, and Docker on the remote host.
• The Dev Container feature is rolling out gradually. If Use Dev Container is missing from the folder menu in the Agents Window, enable the setting manually before troubleshooting anything else.
• Microsoft reports large session lists loading about 12x faster on first listing and about 4x faster on refresh with around 645 sessions. Existing sessions migrate automatically, and users with few sessions will see less difference.
• Organizations that disable Agent mode by account policy should deploy 1.139, because it blocks code --agents and similar paths from bypassing that restriction.
• Editor users get word wrap arrows and no more duplicate closing brackets. If the wrap arrows don't appear, look for editor.wordWrapIndicator in Settings.

Two weekly Stable releases have now taken agent Dev Container sessions from local folders in 1.138 to SSH, Tunnel and WSL hosts in 1.139, all under one setting that Microsoft is still rolling out. For developers who already keep their toolchains in devcontainer definitions on remote machines or in WSL, 1.139 means an agent can use that same container instead of the host's toolchain. For admins, the policy-bypass fix makes 1.139 a version worth enforcing. The next milestone to watch is Microsoft turning chat.agentHost.devContainer.enabled on by default.