[BUG] MSIX-packaged Claude Desktop (Windows) strips PATHEXT to .CPL and empties WINDIR for spawned MCP subprocess shells

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?

What's wrong

On Windows, the MSIX-packaged Claude Desktop spawns MCP subprocess shells with a virtualised environment where PATHEXT is reduced to bare ".CPL" and WINDIR is empty. Any MCP server whose tool spawns a PowerShell subprocess (e.g. Desktop Commander) then cannot resolve native executables by name, and CIM/CDXML PowerShell modules fail to load.

Evidence (direct process-memory reads, Windows Server 2025)

• explorer.exe environment: healthy — PATHEXT full, WINDIR=C:\Windows
• process spawned outside the claude.exe tree (WMI Win32_Process.Create): healthy
• any shell that is a child of claude.exe: PATHEXT=".CPL", WINDIR=""

This localises the stripping to the claude.exe subprocess-spawn boundary. The registry (both Machine and User scopes) is correct. uv is ruled out (no uv process, no uv-launched MCP, installed uv does not reproduce it) — the ".CPL" signature merely coincides with astral-sh/uv#18222.

Symptoms downstream

• PowerShell: "is not recognized" / "Cannot run a document in the middle of a pipeline" for git, cscript, etc.
• Get-Disk / Get-CimInstance Storage cmdlets: "module could not be loaded" (caused by empty WINDIR)

Expected

Spawned MCP subprocesses should receive the normal user/machine environment (PATHEXT and WINDIR intact), as they did under the pre-Feb-2026 Squirrel .exe build.

Environment

• Claude Desktop: MSIX package, Windows
• OS: Windows Server 2025
• Affected MCP: Desktop Commander 0.2.41 (any MCP spawning PowerShell subprocesses is affected)

Related (same MSIX-virtualization root, different symptom)

• #51886 — MSIX desktop app does not propagate CLAUDE_CODE_GIT_BASH_PATH to spawned child (env-isolation; closest analogue — this is the same mechanism affecting a different variable)
• #47977 — MSIX ${__dirname} virtual-path breaks external process spawns (filesystem-side of the same virtualization boundary)

What Should Happen?

Spawned MCP subprocesses should inherit the normal user/machine environment — full PATHEXT (.COM;.EXE;.BAT;.CMD;...) and WINDIR=C:\Windows — exactly as they did under the pre-Feb-2026 Squirrel .exe build. Native executables should resolve by bare name in spawned PowerShell, and CIM/CDXML modules (Get-Disk, Get-CimInstance) should load.

Error Messages/Logs

PATHEXT as seen by a PowerShell subprocess spawned under MSIX Claude Desktop:
  [Environment]::GetEnvironmentVariable("PATHEXT","Process") -> .CPL
  [Environment]::GetEnvironmentVariable("PATHEXT","User")    -> .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.CPL
  [Environment]::GetEnvironmentVariable("PATHEXT","Machine") -> .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
  WINDIR (Process) -> (empty)

Resulting failures:
  git --version  -> "The term 'git' is not recognized..."
  Get-Disk       -> "module 'Storage' could not be loaded"

Steps to Reproduce

1. Install Claude Desktop on Windows via the MSIX package (claude.com/download).
2. Connect an MCP server whose tool spawns a PowerShell subprocess (e.g. Desktop Commander 0.2.41).
3. From that MCP's shell tool, spawn PowerShell and print the env:

$env:PATHEXT ; $env:WINDIR

1. Observe PATHEXT = ".CPL" and WINDIR empty — while the machine and user registry scopes are both healthy.
2. Confirm the boundary: a process spawned OUTSIDE claude.exe (e.g. WMI Win32_Process.Create) shows a healthy env; only children of claude.exe are stripped.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Pre-MSIX Squirrel .exe build (1.1.3189, before Feb 2026)

Claude Code Version

N/A (Claude Code CLI not used) — Claude Desktop MSIX 1.8555.2.0

Platform

Other

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

This is a Claude Desktop (MSIX) bug, surfaced via an MCP server (Desktop Commander). Not a Claude Code CLI issue, but filed here per convention for desktop/MSIX bugs (see related #51886, #47977). Verified via direct process-memory reads — happy to provide the full reproduction transcript if useful.