WSLc integration: Windows-side attach implicitly accesses the default WSL distro's HOME

Summary

When I attach to a WSLc container from VS Code on Windows, Dev Containers also enters the default regular WSL distribution, reads that user's HOME, and installs helper files there. In this case, that distribution is Debian; the selected connection target is a WSLc container.

Please improve WSLc integration so that helper files for this connection are stored either on the Windows side or inside the corresponding WSLc container, according to where the helper needs to run. The default regular WSL distribution's HOME should not be used implicitly for this purpose.

Using wslc as the Dev Containers backend is officially documented by Microsoft.

Environment

Explicit user setting:

{
  "dev.containers.dockerPath": "wslc"
}

The following retain their defaults:

• dev.containers.executeInWSL: false
• dev.containers.forwardWSLServices: true

Steps to reproduce the observed workflow

1. Run VS Code on Windows, with the Dev Containers extension installed and a regular WSL distribution registered as the default.
2. Configure dev.containers.dockerPath to use wslc.
3. From the Windows-side VS Code instance, attach to an existing running WSLc container.
4. Inspect the Dev Containers log and the default regular WSL distribution's HOME.

Actual behavior

The extension first inspects the selected container through wslc. It then opens a separate shell in Debian and obtains that WSL user's home directory.

Sanitized excerpts from the observed connection log:

[2026-11-01T06:56:36.477Z] Start: Run: wslc inspect --type container <container-id>
[2026-11-01T06:56:36.614Z] Start: Run: wsl -d Debian -e /bin/sh -c echo ~
[2026-11-01T06:56:36.748Z] Start: Run: wsl -d Debian -e /bin/sh -c cd '/home/<user>' && /bin/sh
[2026-11-01T07:04:32.348Z] Start: Run in host: mkdir -p '/home/<user>/.vscode-remote-containers/dist'

During this connection, approximately 122 MiB of Node.js, node-pty, and helper code was installed under /home/<user>/.vscode-remote-containers in the regular Debian distribution.

The container's user and HOME are queried separately in later log entries marked Run in container. There are therefore three distinct execution contexts in this workflow: Windows, the default regular WSL distribution, and the selected WSLc container.

Technical context

Inspection of the installed extension indicates that the extra WSL host initialization is gated by forwardWSLServices when the CLI host is not already WSL. This explains a path by which the regular WSL distribution becomes involved.

executeInWSL controls CLI execution, while WSL service forwarding is independent. This distinction helps explain the observed behavior; the requested improvement is to keep helper storage associated with Windows or the selected WSLc container. The observations do not establish that the container's HOME is resolved incorrectly or that every WSLc connection requires a regular WSL distribution.

Expected behavior / requested improvement

For a Windows-side connection to a WSLc container, either of the following storage locations would meet the expectation, depending on the helper's execution context:

1. On Windows: store Windows-side helper files in an appropriate Windows user directory.
2. Inside the corresponding WSLc container: store container-side helper files within the selected container's filesystem, using the appropriate container user's HOME where applicable.

These are acceptable alternatives based on the helper's role, not a request to duplicate the same files in both locations. Attaching to a WSLc container should not implicitly read the default regular WSL distribution's HOME or install .vscode-remote-containers there. Please improve WSLc integration so that helper execution and storage use Windows or the corresponding container rather than an unrelated regular WSL distribution.