Windows: Desktop spawns MCP server processes without PATHEXT, breaking all PowerShell-wrapped servers

**Environment:** Claude Desktop on Windows 11, Windows PowerShell 5.1 as the MCP `command` (`powershell.exe -File .ps1`), server itself in Python.

**Symptom:** The wrapper cannot resolve *any* bare command name — `git`, `py`, `python`, `python3` all raise `CommandNotFoundException` — even though Desktop's own log line ("Using MCP server command … with path") shows a complete, correct PATH containing every one of those tools, and the same commands resolve fine in any interactive shell. The server exits and Desktop logs only "Server disconnected", which points nowhere near the cause.

**Root cause:** The spawned child receives `PATH` but **not `PATHEXT`**. Without `PATHEXT`, PowerShell 5.1 cannot map a bare name (`git`) to its executable (`git.exe`), so PATH lookup finds nothing. A side effect under `Set-StrictMode`: on a session where no native command has ever run, reading `$LASTEXITCODE` throws `The variable '$LASTEXITCODE' cannot be retrieved because it has not been set` — which is how the failure often *presents*, several layers away from the missing variable.

**Reproduction (controlled):** Launch `powershell.exe -NoProfile -File probe.ps1` from a parent whose environment contains the full normal `PATH` but no `PATHEXT` (e.g. via `Start-Process` with an explicit environment). `probe.ps1` runs `Get-Command git` and `& py -3 -V`. Result: both fail exactly as in Desktop's spawn. Add `PATHEXT=.COM;.EXE;.BAT;.CMD` to the same environment: both succeed. One variable flips the whole behavior.

**Impact:** Every MCP server wrapped in a PowerShell (or cmd) launcher on Windows — a common pattern for loading credentials or selecting an interpreter before exec — fails at startup with misleading diagnostics. The failure is invisible in Desktop's logs because the PATH it prints is fine; the variable it *didn't* pass is what's missing. We hit this in production with non-technical users on real desks; the field logs showed a perfect 24-entry PATH beside total resolution failure.

**Suggested fix:** Include `PATHEXT` (and consider other resolution-relevant variables such as `PSModulePath`) in the child environment Desktop constructs — or inherit the parent environment and overlay, rather than allow-listing. Failing that, document the spawn environment's exact contents for server authors.

**Workarounds we ship meanwhile:** defaulting `PATHEXT` to the stock Windows value at the top of our wrapper when absent; or adding `PATHEXT` to the server's `env` block in `claude_desktop_config.json`.

Made with [Orca](https://github.com/stablyai/orca) 🐋

Reproduce the failure with powershell.exe -NoProfile -File probe.ps1 from an environment containing PATH but no PATHEXT, then repeat with PATHEXT=.COM;.EXE;.BAT;.CMD. Trace the Windows Desktop MCP child-process environment construction and verify that a PowerShell-wrapped server can resolve git or py. Done means the child receives the required resolution environment and the reproduction succeeds without requiring a server env workaround.

Scritto dal modello di indicizzazione a partire dal testo della issue.