claude-code - 💡(How to fix) Fix [BUG] MCP Desktop Extensions Fail on MSIX-Packaged Claude Desktop (Windows) [1 participants]

Environment Claude Desktop version: 1.1617.0.0 (MSIX package ID: Claude_pzs8sxrjxfjjc) OS: Windows (Enterprise, managed via Microsoft Intune) Extension: Windows-MCP (ant.dir.cursortouch.windows-mcp) Deployment: MSIX distributed via Intune to corporate devices Error Message Unable to connect to extension server. Please try disabling and re-enabling the extension. Relevant Log (mcp-server-Windows-MCP.log) [Windows-MCP] [info] Using MCP server command: uv with args and path 'uv' is not recognized as an internal or external command, operable program or batch file. [Windows-MCP] [error] spawn uv ENOENT at ChildProcess._handle.onexit (node:internal/child_process:294:12) [Windows-MCP] [error] Server disconnected. Root Cause Analysis The MSIX packaging format runs Claude Desktop in a virtualized sandbox via the Windows App Model runtime. This sandbox constructs a minimal process environment that includes only machine-level PATH entries (HKLM) and excludes user-level PATH entries (HKCU). uv (the Python package manager required by most MCP extensions) installs itself to %USERPROFILE%.local\bin and registers only in user-level PATH — making it invisible to Claude Desktop despite being correctly installed and accessible from any normal terminal session. Additionally, the MSIX package virtualizes %APPDATA%, causing the "Edit Config" button in Claude Desktop to open the wrong config file (%APPDATA%\Claude\claude_desktop_config.json which doesn't exist), instead of the correct virtualized path: %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json Impact Affects all enterprise customers deploying Claude Desktop via Intune/MSIX Every MCP extension that relies on uv (Python) or npx/node (JavaScript) fails out of the box No workaround is available to end users without admin rights Current Workaround Copy runtimes to a machine-level PATH location visible to the sandbox: powershell Copy-Item "$env:USERPROFILE.local\bin\uv.exe" "C:\Windows\System32\uv.exe" -Force Copy-Item "$env:USERPROFILE.local\bin\uvx.exe" "C:\Windows\System32\uvx.exe" -Force This must be deployed via an Intune remediation script on every managed device — it is not scalable. Proposed Fix Add desktop6:EnvironmentVariables to the AppxManifest.xml to expose user PATH to the sandboxed process: xml desktop6:EnvironmentVariables <desktop6:EnvironmentVariable Name="PATH" Value="%USERPROFILE%.local\bin;[EXISTING_PATH]"/> </desktop6:EnvironmentVariables> Alternatively, Claude Desktop could resolve the runtime path at startup by scanning common install locations (%USERPROFILE%.local\bin, %APPDATA%\npm, etc.) and injecting them into the child process env before spawning MCP servers — similar to how VS Code handles this.

Fix / Workaround

Environment Claude Desktop version: 1.1617.0.0 (MSIX package ID: Claude_pzs8sxrjxfjjc) OS: Windows (Enterprise, managed via Microsoft Intune) Extension: Windows-MCP (ant.dir.cursortouch.windows-mcp) Deployment: MSIX distributed via Intune to corporate devices Error Message Unable to connect to extension server. Please try disabling and re-enabling the extension. Relevant Log (mcp-server-Windows-MCP.log) [Windows-MCP] [info] Using MCP server command: uv with args and path 'uv' is not recognized as an internal or external command, operable program or batch file. [Windows-MCP] [error] spawn uv ENOENT at ChildProcess._handle.onexit (node:internal/child_process:294:12) [Windows-MCP] [error] Server disconnected. Root Cause Analysis The MSIX packaging format runs Claude Desktop in a virtualized sandbox via the Windows App Model runtime. This sandbox constructs a minimal process environment that includes only machine-level PATH entries (HKLM) and excludes user-level PATH entries (HKCU). uv (the Python package manager required by most MCP extensions) installs itself to %USERPROFILE%.local\bin and registers only in user-level PATH — making it invisible to Claude Desktop despite being correctly installed and accessible from any normal terminal session. Additionally, the MSIX package virtualizes %APPDATA%, causing the "Edit Config" button in Claude Desktop to open the wrong config file (%APPDATA%\Claude\claude_desktop_config.json which doesn't exist), instead of the correct virtualized path: %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json Impact Affects all enterprise customers deploying Claude Desktop via Intune/MSIX Every MCP extension that relies on uv (Python) or npx/node (JavaScript) fails out of the box No workaround is available to end users without admin rights Current Workaround Copy runtimes to a machine-level PATH location visible to the sandbox: powershell Copy-Item "$env:USERPROFILE.local\bin\uv.exe" "C:\Windows\System32\uv.exe" -Force Copy-Item "$env:USERPROFILE.local\bin\uvx.exe" "C:\Windows\System32\uvx.exe" -Force This must be deployed via an Intune remediation script on every managed device — it is not scalable. Proposed Fix Add desktop6:EnvironmentVariables to the AppxManifest.xml to expose user PATH to the sandboxed process: xml desktop6:EnvironmentVariables <desktop6:EnvironmentVariable Name="PATH" Value="%USERPROFILE%.local\bin;[EXISTING_PATH]"/> </desktop6:EnvironmentVariables> Alternatively, Claude Desktop could resolve the runtime path at startup by scanning common install locations (%USERPROFILE%.local\bin, %APPDATA%\npm, etc.) and injecting them into the child process env before spawning MCP servers — similar to how VS Code handles this.