[BUG] Desktop (Windows + WSL): file links in a WSL session cannot be opened; they are read from the Windows side instead of through the WSL connection
Environment
- Claude desktop app on Windows, Code tab, session running in WSL 2 (Ubuntu 22.04.4 LTS)
- Claude desktop 2.37337.1 (ba51ab), 2026-10-13
- Claude Code 2.1.294 in WSL
What happens
In a session whose folder lives in WSL, the agent links files it has written as markdown links (relative paths
inside the session folder, and absolute paths in the session's scratchpad directory under /tmp/claude-<uid>/…).
Clicking any of those links in the desktop app does not show the file: every file link fails, in the session folder and in the scratchpad alike. The paths are WSL paths, and the app appears to
try to read them directly from the Windows side, where they do not exist.
Expected
A file a WSL-backed session creates is opened through the WSL connection the session already uses: the file pane
reads it from the WSL filesystem (for example through the session's own WSL bridge, or \\wsl.localhost\<distro>\…),
so that links to files in the session folder and in the scratchpad open as they do in a local Windows session.
Why it matters
The agent's own guidance tells it to link files in the session folder and the scratchpad for the user to open in the
file pane. In a WSL session every such link is dead, so generated reports, drafts and scripts can only be read by
asking the agent to print them.
Related
#100742 (Files/Git panels not loading in WSL sessions until the session starts) is about the same panels, but not
about opening a linked file.