`/desktop` fails to launch Claude Desktop when installed via MSIX/AppX package (Windows)

Environment

• Host OS: Windows 11 Pro 10.0.26200
• Claude Code CLI is running inside WSL (Debian), not natively on Windows. Working directory is under \\wsl.localhost\Debian\home\....
• Claude Desktop: installed as MSIX/AppX package on the Windows host (not inside the WSL distro)
• Package: Claude_1.18286.2.0_x64__pzs8sxrjxfjjc
• Install location: C:\Program Files\WindowsApps\Claude_1.18286.2.0_x64__pzs8sxrjxfjjc
• AppID (from Get-StartApps): Claude_pzs8sxrjxfjjc!Claude
• %LOCALAPPDATA%\Claude contains only a Logs subfolder — no directly accessible executable

Steps to reproduce

1. Have Claude Desktop installed via the MSIX/AppX package (e.g. from Microsoft Store or an MSIX-based installer) rather than a traditional installer.
2. Run /desktop in Claude Code (CLI).

Expected behavior

Claude Desktop opens.

Actual behavior

/desktop reports:

Failed to open Claude Desktop. Please try opening it manually.

On a later attempt, it instead returned:

Cancelled. Learn more about Claude Desktop at https://clau.de/desktop

Manually launching Claude Desktop from the Start menu works fine — the app itself is correctly installed and functional. The issue appears limited to how /desktop attempts to locate/launch the app.

Suspected cause

Two compounding factors:

1. WSL → Windows host boundary: the Claude Code process runs as a Linux process inside WSL, while Claude Desktop is a Windows-host application. Launching it requires bridging through Windows interop (e.g. invoking explorer.exe, cmd.exe /c start, or powershell.exe Start-Process from WSL) rather than a same-OS process launch. /desktop may be attempting a launch mechanism that assumes it is already running natively on the target OS (as it would on macOS or native Windows), which does not apply when invoked from inside WSL.
2. MSIX/AppX packaging: even on native Windows, C:\Program Files\WindowsApps\ is a virtualized, ACL-protected directory — a direct executable path or plain ShellExecute-style launch fails there. Packaged apps must be activated via shell:AppsFolder\<AppID> or the Start menu, not a direct file path.

Combined, /desktop would need to shell out from WSL to a Windows interop binary (e.g. explorer.exe) and target it at the MSIX AppID rather than a file path — it currently seems to do neither successfully.

Suggested fix / workaround

• Detect when Claude Code is running under WSL and the target app is Windows-hosted; shell out via WSL interop (explorer.exe is reachable from WSL by default) rather than attempting a native Linux launch.
• Detect MSIX-installed Claude Desktop (e.g. via Get-AppxPackage through interop) and launch it through explorer.exe shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude (or the equivalent ApplicationActivationManager API) instead of a direct executable path.
• As a workaround, users can launch Claude Desktop manually from the Start menu, or run from a WSL shell:

``
explorer.exe shell:AppsFolder\\Claude_pzs8sxrjxfjjc\!Claude
``