Desktop app on Windows should execute natively in WSL for projects on \wsl.localhost\ paths

Problem

When I open a project that lives on WSL in the Claude Code desktop app on Windows, the working directory shows as \wsl.localhost\Ubuntu\home\<user>\<project>. The app then runs Windows binaries — Git Bash, Windows Node, Windows pnpm — against that SMB-mounted path. Every friction I hit is downstream of this one choice:

• pnpm install fails with EISDIR on node_modules/vite because pnpm's symlink model doesn't cross the mount cleanly
• node_modules/<pkg> symlinks show as EIO / Input/output error from the Windows side even when they resolve fine from inside WSL
• Subagents launched via the Agent tool get sandboxed away from the UNC path and fail every filesystem tool with "Permission denied" (related: #5465, #25526, #22665 — I'm not filing on top of those because they treat the symptom)
• The whole experience is substantially more broken than VS Code's Remote-WSL extension, which handles this case natively

Expected

When the desktop app detects the cwd is a WSL path, it should dispatch all shell / Bash / subprocess / subagent tool calls through wsl.exe -d <distro> -e bash -c "..." so the entire tool stack runs inside Linux against native /home/... paths. VS Code does this. Cursor does this. Claude Code doesn't.

Current workarounds (none are good)

• Launching claude CLI from inside a WSL terminal — works, but abandons the desktop app the user picked on purpose
• Moving the project to C:\ — not acceptable, it's a real WSL project
• Mapping WSL to a drive letter / NTFS junction — doesn't help, the block is tooling choice, not path resolution

Repro

1. Open Claude Code desktop app on Windows 11
2. Open a folder at \wsl.localhost\Ubuntu\home\<user>\<project>
3. Run pnpm install via Bash tool → EISDIR on a random node_modules/*
4. Launch any subagent → all filesystem tools fail Permission denied

Why this matters

Every dev I know who uses WSL keeps their projects on the Linux side (per Microsoft's own guidance — WSL1/2 perf is terrible through the Windows mount). The desktop app is effectively unusable for that population without this fix.

---

_Issue body drafted by Claude Code (Opus 4) at the user's request — repro is from a real session today._