[Bug] Choosing VS Code for a delivered file opens a Windows-side window instead of reusing the existing Remote-WSL window

[sui-zhiyuan]

1. Summary

On a delivered-file card in the dsh Web UI, choosing VS Code from the card's application menu
launches the file through a Windows-side Shell association handler, so it appears in a new Windows
window (pointing at \\wsl.localhost\...) instead of in the Remote-WSL window that already has the
project open.

2. Environment (complete)

Item	Value
Host OS	Windows 11 x64, build 10.0.26200 (code --status reports Windows_NT x64 10.0.26200)
WSL	WSL2, kernel 6.18.33.2-microsoft-standard-WSL2, distro Ubuntu 26.04.1 LTS, WSL_DISTRO_NAME=Ubuntu
dsh	0.2.0-rc.2 (dsh --version); Node v26.8.1, pnpm 12.9.1; profile web; Web UI at http://127.0.0.1:3080
VS Code	1.140.0, commit 07f806f999227108933c2e30515b26eecc1fda74, x64, installed on the Windows side
Extension	ms-vscode-remote.remote-wsl 0.104.3 (Windows side)
Relevant packages (loaded in the profile)	@deepseek-ai/dsh-api-session-controller@0.2.0-rc.2, @deepseek-ai/dsh-native-command@0.2.0-rc.2, @deepseek-ai/dsh-client-ui-deliverables@0.2.0-rc.2, @deepseek-ai/dsh-client-ui-open-in-app@0.2.0-rc.2, @deepseek-ai/dsh-host-open-in-app@0.2.0-rc.2
Already-open VS Code window	Remote-WSL window; Process Argv is --folder-uri=vscode-remote://wsl+Ubuntu/home/<user>/<project> --remote=wsl+Ubuntu (visible in code --status)
Why the menu branch is the subject	The Windows default handler for .ts is not VS Code, so the reproduction below necessarily travels the explicit-application= handler branch, not the default association

3. Steps to reproduce

Preconditions:

• VS Code has the WSL project open on the Windows side (a Remote-WSL window);
• the dsh Web UI runs inside that same WSL distro, with the session cwd at the project root;
• the session has produced at least one file through present (a .ts file here).

Steps:

1. In the dsh Web UI, find the delivered-file card below a reply.
2. Open the card's application menu and choose VS Code.
   
3. Observe: a new Windows-side VS Code window appears; the already-open Remote-WSL window is not
   focused.

4. Expected behaviour

The file opens in the already-open Remote-WSL window — equivalent to running
code <absolute file path> inside WSL, which the wrapper chain expands to
--file-uri=vscode-remote://wsl+Ubuntu/<path> --remote=wsl+Ubuntu and therefore reuses that window.

5. Actual behaviour

Windows Shell starts VS Code — a new/local window on a path like
\\wsl.localhost\Ubuntu\... — and the Remote-WSL window is not reused.

6. Preliminary analysis and evidence

Preliminary: this is derived from the installed package sources plus the observed request and
behaviour; no host-side logging was instrumented.

Equivalent direct reproduction: the request the menu selection sends, and the entry point traced
below.

POST /api/present.open?sessionId=<sessionId>&seq=<seq>&index=<index>&action=open
     &application=C%3A%5CUsers%5C<user>%5CAppData%5CLocal%5CPrograms%5CMicrosoft%20VS%20Code%5CCode.exe

Call chain (each hop verified in the installed packages):

1. The card renders the slot deliverables.file.actions (dsh-client-ui-deliverables/lib/client.js:1702),
   filled on the client by FileRouteAction — the control whose menu carries the VS Code entry
   (dsh-client-ui-open-in-app/lib/client.js:884).
2. POST /api/present.open (dsh-client-ui-deliverables/lib/index.js:48-76) → openVerified
   (:128-143) → ctx.sessionController.openWorkspacePath(...).
3. SessionController.openWorkspacePath: with application !== undefined it calls
   openFileApplication (dsh-api-session-controller/lib/index.js:3031-3040) → dsh-native-command's
   openNativeFileApplication.
4. WSL detection: desktopTarget() re-classifies the platform as win32 because
   nativeFileManager() === "explorer", and resolves the Windows path via wslpath -w
   (dsh-native-command/lib/index.js:910-928).
5. windowsFileApplications() embeds the path and the application as base64 into a temporary script
   and runs powershell.exe -NoProfile -NonInteractive -STA -ExecutionPolicy Bypass -File <tmp>/associations.ps1
   (:676-705).
6. That script calls the inline C# [DshFileAssociations]::Open($path, $application) (C# source
   constant WINDOWS_ASSOCIATIONS, :438-666): SHAssocEnumHandlers finds the matching handler,
   then SHCreateItemFromParsingName(path) → BindToHandler(BHID_DataObject) →
   IHandler::Invoke(IDataObject) (:648-671).
7. Windows Shell therefore launches its associated application on a Windows path. No
   --remote=wsl+<distro> and no --file-uri=vscode-remote://… is ever involved, so entering the
   existing Remote-WSL window is structurally impossible.

Local measurement supporting the expected behaviour: code <file> inside WSL expands to
--file-uri=vscode-remote://wsl+Ubuntu/… --remote=wsl+Ubuntu and reuses the existing window (window
count unchanged).