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.

Start with the reported AppData/Local/Claude/logs/main.log SSH spawn entries and desktop-wsl.md, then trace how +New > Local selects its session-spawn path. Reproduce on the affected x86_64 machine and compare with the working ARM64 machine. Done means Local uses native Windows Git Bash, reports the expected UNC path, and the browser pane/MCP log appears.

Rédigé par le modèle d'indexation à partir du texte de l'issue.