Open in → VS Code/Cursor passes untranslated Linux paths under WSL
Bug: "Open in → VS Code/Cursor" passes untranslated Linux paths when Claude Code runs in WSL
What happens
Claude Code runs inside WSL2 (Ubuntu); the desktop app runs on Windows. Right-clicking a
file in the diff pane → Open in → VS Code (or Cursor) launches the editor but never
opens the file — the window flashes, then settles into a bare WSL remote window showing
"No Folder Opened".
Both editors fail identically, so this is not editor-specific.
Separately: no "Open in editor" affordance appears anywhere in the UI for this session.
Cause (verified in-session)
The Linux path (/home/<user>/projects/...) is handed to the Windows-side editor launcher,
which cannot resolve it. Windows has no /home/<user>.
The handoff needs one of these translations, and currently does neither:
- UNC path:
\\wsl.localhost\Ubuntu\home\<user>\projects\test_econ_repo\desktop_test.md - Remote flag:
code --remote wsl+Ubuntu /home/<user>/projects/test_econ_repo/desktop_test.md
The second is what the WSL code wrapper does automatically — which is why launching from a
WSL shell works and the menu does not.
Repro
- Run Claude Code in WSL2 (Ubuntu) from the Windows desktop app.
- Have it create or modify a file in the repo.
- Right-click the file in the diff pane → Open in → VS Code (or Cursor).
- Editor opens to an empty WSL remote window; the file is not opened.
Evidence
- Windows VS Code 1.137.0, commit
645f29cc3176500b4b5762ba887cf2a7f0ffdf2c - WSL server present at
~/.vscode-server; distro nameUbuntu coderesolves to the Windows install under/mnt/c/.../Microsoft VS Code/bin/code- Running
code --remote wsl+Ubuntu <linux path>from inside WSL returns
Option 'remote' is defined more than once. Using value 'wsl+Ubuntu'.
and opens the file correctly — confirming the wrapper injects --remote, and that the
same path works once translated.
Workaround
Launch from a WSL shell, where the wrapper handles translation:
code ~/projects/test_econ_repo/desktop_test.md