Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix Desktop app on Windows should execute natively in WSL for projects on \wsl.localhost\ paths [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#49331•Fetched 2026-04-17 08:44:16
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Author
ESkeltonUniverusESkeltonUniverus
Participants
ESkeltonUniverusESkeltonUniverusvolarnamevolarname
Timeline (top)
labeled ×5commented ×1

Error Message

  • node_modules/<pkg> symlinks show as EIO / Input/output error from the Windows side even when they resolve fine from inside WSL

Root Cause

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.

Fix Action

Fix / Workaround

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)

RAW_BUFFERClick to expand / collapse

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.

extent analysis

TL;DR

The most likely fix is to modify the Claude Code desktop app to run shell and subprocess tool calls through wsl.exe when the working directory is a WSL path.

Guidance

  • Identify the condition under which the working directory is detected as a WSL path and modify the app to use wsl.exe -d <distro> -e bash -c "..." for shell and subprocess calls.
  • Verify that the wsl.exe command is properly configured and functional on the system.
  • Consider implementing a fallback or error handling mechanism for cases where wsl.exe is not available or fails.
  • Review the current workarounds and assess whether any can be improved or combined to provide a temporary solution.

Example

# Example of running a command through wsl.exe
wsl.exe -d Ubuntu -e bash -c "pnpm install"

Notes

The solution relies on the availability and proper configuration of wsl.exe on the system. Additionally, the implementation details may vary depending on the specific requirements and constraints of the Claude Code desktop app.

Recommendation

Apply a workaround by modifying the app to use wsl.exe for shell and subprocess calls when the working directory is a WSL path, as this approach is already used by other tools like VS Code and Cursor.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#output truncation#response parsing#generation error#database connection#vector store

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING