WSL-path folder selection forces "WSL" environment instead of "Local", breaking Chrome extension and MCP plugins (regression)
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
When I select a folder that lives on a WSL path in Claude Code Desktop, the app now forces the environment to "WSL" instead of allowing "Local". While the environment is forced to "WSL", Claude Code cannot use the Chrome browser extension or other MCP plugins.
This is a regression in the latest version. Last week, I was able to select "Local" as my environment while working on a WSL-mounted code path, which let me use the Chrome extension and other MCP extensions without any issue.
What Should Happen?
Selecting a folder on a WSL path should still allow me to choose the "Local" environment (as it did in the previous version), so that the Chrome browser extension and other MCP plugins remain available while working on a WSL-mounted code path.
Error Messages/Logs
Steps to Reproduce
- Update Claude Code Desktop to the latest version.
- Open/select a folder that lives on a WSL path (e.g. a project on the WSL filesystem).
- Observe that Claude Code Desktop automatically forces the environment to "WSL", with no option to switch it to "Local".
- Attempt to use the Chrome browser extension or another MCP plugin.
- Observe that the Chrome extension and MCP plugins are unavailable while the environment is forced to "WSL".
Expected (and prior) behavior: In last week's version, I could select the "Local" environment while working on the same WSL-mounted code path, and the Chrome extension and other MCP plugins worked normally.
Claude Model
Not sure / Multiple models
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
Version 1.21459.0 (f7518f)
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
WSL (Windows Subsystem for Linux)
Additional Information
_No response_
3 Comments
Same here — can confirm this regression on Claude Desktop 1.21459.3 (MSIX),
Windows + WSL2 (Ubuntu), with projects on \\wsl.localhost\...
Selecting a \\wsl.localhost\... project folder auto-switches the environment to
WSL, with no way to keep it Local. I tried two workarounds and both still flip
to WSL:
As a result, Claude-in-Chrome is gone (a WSL session reads the Linux
~/.claude.json for MCP, not my Windows Desktop config where the Chrome
integration is set up), and my other Windows-side MCP servers are unavailable too.
One extra symptom that looks like it comes from the same change: after the
update, all my existing Code sessions disappeared from the Desktop sidebar. The
data is NOT lost — the .jsonl transcripts are intact under
%USERPROFILE%\.claude\projects\, and
claude --resumein a Windows terminalstill lists all of them. What got wiped is the Desktop's session index
(...\Claude\claude-code-sessions\<userId>\<profileId>\local_*.json). Even after
rebuilding those wrapper files, the sidebar stays empty — because these projects
now open in WSL context, so Desktop looks at the WSL side instead of the
Windows-side sessions that created them.
Request: please add an option to open \\wsl.localhost / \\wsl$ paths as a Local
(Windows) session (i.e., opt out of the automatic WSL routing). That one toggle
would restore Chrome + Windows-side MCP servers and make the previous Code
sessions visible again.
Same here, the exact issues that @JasonKeirstead mentioned. I'm on Claude for windows Version 1.22209.3 (babe11)
Any updates to this? Did you find a workaround?