Windows Desktop app: "+New > Local" session spawns via SSH into WSL instead of native Windows, so the browser pane never appears

Title: Windows Desktop app: "+New > Local" session spawns via SSH into WSL instead of native Windows, so the browser pane never appears

Summary

On one Windows machine (x86_64), opening a session via +New > Local in the Claude Code desktop app does not behave like a Local session should. Instead of running as a native Windows process (Git Bash), the app spawns it via SSH directly into the WSL distro — identical to what +New > WSL does. As a documented consequence (per desktop-wsl.md: "the file browser pane" is one of the features "not available in WSL sessions yet"), the in-app browser/live-preview pane never appears, no matter how many times the session is recreated.

A second Windows machine (ARM64), using the same app, same account, same repo, does not have this problem — +New > Local behaves as documented (native Windows spawn, UNC-style pwd, working browser pane).

Environment

• Affected machine: Windows 11, x86_64, 8-core/32GB RAM
• Working machine: Windows 11, ARM64, 4-core/16GB RAM
• WSL distro: Ubuntu 26.04 LTS ("Resolute Raccoon"), kernel 6.18.33.2-microsoft-standard-WSL2
• Remote CLI version seen in logs: ccd-cli 2.1.237
• App updater-reported version: 1.34493.1 (from config.json's updaterLastSeenVersion)

What I expected

+New > Local on the affected (x86) machine should launch a native Windows Git Bash process, giving:

• pwd reporting the UNC path //wsl.localhost/Ubuntu/home/eric/stance
• The Claude_Browser MCP tool / browser-live-preview pane available

What actually happens

pwd inside the "Local" session reports a bare Linux path (/home/eric/stance), and no browser-pane MCP tool is ever injected.

AppData/Local/Claude/logs/main.log shows, for every Local session opened on this machine:

2026-08-25 05:34:15 [info] Starting local session local_9bed2db9-... in /home/eric/stance
2026-08-25 05:34:15 [info] [SSH] Using remote spawn function for session local_9bed2db9-... on wsl:Ubuntu (cli: /home/eric/.claude/remote/ccd-cli/2.1.237)

logs/mcp.log stays empty (0 bytes) across these sessions — consistent with the browser MCP server never starting.

What I've ruled out

1. Stale/carried-over WSL state. This WSL distro's ~/.claude directory may originally have come from an older machine via a tarball copy, so I suspected the app might be detecting a pre-existing ~/.claude/remote/ remote-spawn registration and preferring it over a fresh native-Windows setup. I renamed ~/.claude/remote out of the way and restarted the Claude app. The app regenerated a brand-new ~/.claude/remote/ directory on restart, and the very next +New > Local session still went straight to [SSH] Using remote spawn function ... on wsl:Ubuntu — same behavior, with a completely fresh remote-daemon registration. So this isn't about stale state.
2. CPU architecture. I initially suspected an ARM vs. x86 split (working machine is ARM, broken one is x86), but that seems unlikely given x86 is the dominant Windows platform, and the desktop docs list official installers for both x64 and ARM64 with no browser-pane caveat for either.

Ask

Is there a way to force a "Local" session to actually take the native-Windows spawn path instead of the SSH/WSL path? Is this a known fallback behavior (e.g. triggered by some WSL/SSH capability being detected as "already available" on this machine), and if so, is there a setting to disable it?

Happy to provide more logs / repro steps if useful.