Dev Containers boots local default WSL distro on "Reopen in Container" with Remote-SSH Docker host, even with dev.containers.executeInWSL explicitly false

[alexdelprete]

VS Code Version: 1.135.0 (08d4889f9ec4a1685d257b9b95de036c8e1ce1e5)
Local OS Version: Windows 11
Remote OS Version: Debian 13 (LXC), Docker 29.7.2, reached via Remote-SSH
Remote Extension/Connection Type: Remote-SSH + Dev Containers
Extension versions: ms-vscode-remote.remote-containers@0.467.0, ms-vscode-remote.remote-ssh@0.129.2026082615
Relevant settings: "dev.containers.executeInWSL": false (set explicitly; behavior identical when unset)

Steps to Reproduce

1. Start VS Code with no workspace — wsl -l --running is empty
2. Remote-SSH connect to the Linux host running Docker — WSL still not started
3. Open a folder on that host containing .devcontainer.json — WSL still not started
4. Run Dev Containers: Reopen in Container — the local default WSL distro boots (vmmemWSL ~1.4 GB)

Observed

The Dev Containers log shows the extension resolving the remote authority, then immediately enumerating and booting local WSL:

[2114 ms] Host authority: ssh-remote+devbox.axel.dom
[2119 ms] Start: Run: wsl -l -v
[2241 ms] Start: Run: wsl -d Debian -e /bin/sh -c echo ~
[5875 ms] Start: Run: wsl -d Debian -e /bin/sh -c cd '/home/aless' && /bin/sh

Inside that WSL shell it probes for a vscode-server/CLI installation (test -f /home/aless/.vscode-server/cli/servers/.../node etc., all Exit code 1) and runs a userEnvProbe against WSL bash — all before Start: Check Docker is running, which then correctly talks to the remote Docker host. The spawned shell lingers, keeping the WSL2 utility VM alive. Process tree confirms the spawn's parent is VS Code's NodeService utility process.

Everything container-related happens on the remote host; local WSL is unrelated to this topology.

The probe appears to be unconditional

After fully removing WSL from the machine — all distros unregistered, wsl --uninstall, and the WSL optional feature disabled via dism /online /disable-feature /featurename:Microsoft-Windows-Subsystem-Linux — "Reopen in Container" still invokes wsl.exe:

[3215 ms] Setting up container for folder or workspace: /home/alexdelprete/dev/hass/ha-4noks-elios4you
[3217 ms] Host authority: ssh-remote+devbox.axel.dom
[3222 ms] Start: Run: wsl -l -v
[3288 ms] Could not connect to WSL.
[3289 ms] Command failed: wsl -l -v
[3290 ms]
[3293 ms] The Windows Subsystem for Linux is not installed. You can install by running 'wsl.exe --install'.
For more information please visit https://aka.ms/wslinstall

[3387 ms] Start: Check Docker is running
[3390 ms] Start: Run: docker version
[3443 ms] Client: Docker Engine - Community
 Version:           29.7.2

When the inbox wsl.exe stub is reached interactively, it prompts the user to install WSL:

Windows Subsystem for Linux must be updated to the latest version to proceed. You can update by running 'wsl.exe --update'.
For more information please visit https://aka.ms/wslinstall

Press any key to install Windows Subsystem for Linux.
Press CTRL-C or close this window to cancel.
This prompt will time out in 60 seconds.

So the call is gated neither on WSL being installed, nor on dev.containers.executeInWSL, nor on the workspace being a WSL folder. The failure is non-fatal and the result is unused — the container connect proceeds to the remote Docker host and completes normally. The probe is pure overhead: ~4 s and ~1.4 GB of vmmemWSL when a distro exists, an install prompt when one does not.

Expected

Per the setting's own description — "The default is to only execute in WSL for workspace folders in WSL" — a Remote-SSH workspace should never invoke local WSL, and certainly not with dev.containers.executeInWSL explicitly false.

Ruled out

• WSL extension (uninstalled — behavior persists)
• Docker Desktop (its distro stays Stopped throughout; later uninstalled entirely — behavior persists)
• Terminal session restore (terminal.integrated.persistentSessionReviveProcess: "never" set)
• Other extensions (steps 1–3 produce no WSL activity; the boot occurs only on the Reopen command)

Related

• "dev.containers.executeInWSL": false doesn't work at all #9194 — same setting ignored; marked fixed in Dev Containers 0.321. This appears to be a recurrence for the Remote-SSH-hosted-Docker topology.
• Dev Containers fails to attach on macOS when targeting WSL-hosted containers via Remote SSH (ENOENT: spawn wsl) #11303 — possibly related (spawn wsl attempted in a remote scenario on macOS).

Does this issue occur when you try this locally?: N/A (requires remote Docker host)
Does this issue occur when you try this locally and all extensions are disabled?: N/A