WSL shells in non-WSL (Windows-native) windows do not get remote-cli access

[ELLIOTTCABLE]

Type: Bug

When working in vscode-remote or vscode-wsl, the code (or code-insiders) command will helpfully open files in the current window.

However, when using WSL as your terminal for a normal, non-vscode-wsl remote-mode window, the code command launches a new, WSL-mode window on the same folder you're already looking at.

I'm able to reproduce this with all extensions disabled, in an as-default-as-I-could-make-it WSL environment - inside that WSL-bash shell, code evaluates to the raw parent executable, not the vscode-remote-cli:

$ which code
/mnt/c/Users/ec/AppData/Local/Programs/Microsoft VS Code/bin/code

And if I attempt to explicitly use remote-cli/code, it produces an error, as no remote-access socket has been established:

$ ~/.vscode-server/bin/cd4ee3b1c348a13bafd8f9ad8060705f6d4b9cba/bin/remote-cli/code .gitignore
Command is only available in WSL or inside a Visual Studio Code terminal.

(Which is a misleading error-message, by the way, because I'm in both WSL and a VScode terminal. :P)

• Behaviour is the same whether terminal.integrated.shellIntegration is enabled or not; behaviour is the same whether I chsh to bash or zsh in the Ubuntu WSL.

• Behaviour is the same whether I provide an argument to wsl.exe or not:

         "Ubuntu (WSL)": {
  -         "path": "C:\\WINDOWS\\System32\\wsl.exe",
  -         "args": ["-d", "Ubuntu"]
  +         "path": "C:\\WINDOWS\\System32\\wsl.exe"
         }

• code works as expected in a git-bash or PowerShell terminal from a Windows-filesystem VScode window; ditto for a WSL-bash shell from a WSL-filesystem VScode window. It's only the pairing of Windows-filesystem VScode window and wsl.exe integrated terminal host that fails.

• This may be a regression; I've had previous issues ('code' (and 'code-insiders') get injected into WSL-bash, but not into WSL-zsh vscode-remote-release#6641, also see remote-cli code command works in bash, but zsh or tmux #236401) with code access from integrated terminals over VScode-remote, or in Zsh, and the like; but it's always at least worked in Bash. For me, having it fail in default Bash is new.

Expected behaviour:

The code command performs the same, by default, in one of the default terminal profiles (configured as documented here [as of 7c199a]) as it does in any of the other terminals with shell integration: it connects to the running VScode instance, and adds the passed path to the set of open editors.

Versions:

VS Code version: Code 1.96.4 (cd4ee3b, 2025-01-16T00:16:19.038Z)
OS version: Windows_NT x64 10.0.26100
Modes:

System Info

Item	Value
CPUs	13th Gen Intel(R) Core(TM) i9-13900KS (32 x 3187)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: enabled_on direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_graphite: disabled_off video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: enabled webnn: disabled_off
Load (avg)	undefined
Memory (System)	31.71GB (5.05GB free)
Process Argv	--crash-reporter-id 26676505-77e1-431f-93ba-046f26f2b2af
Screen Reader	no
VM	0%

Extensions disabled