[BUG] /desktop fails on Windows when Claude Desktop is installed as MSIX/Store package (refile of #36079)

Confirmed Workaround (tested on Windows 11 Pro, CLI 2.1.143, Store package 1.7196.0.0)

Hit the same issue independently and found that a protocol-forwarding shim at the expected path fully resolves it. This also fixes a related problem: the Desktop app's local session discovery (LocalSessions) failing to show active CLI sessions in the sidebar via Remote Control.

The fix (takes 30 seconds)

1. Compile a 3KB shim executable:

// Save as Claude.cs anywhere, then compile
using System.Diagnostics;
class Program {
    static void Main(string[] args) {
        string uri = "claude://";
        if (args.Length > 0) uri = args[0];
        if (!uri.StartsWith("claude://")) uri = "claude://" + uri;
        Process.Start(new ProcessStartInfo(uri) { UseShellExecute = true });
    }
}

$dir = "$env:LOCALAPPDATA\Programs\claude-desktop"
New-Item -ItemType Directory -Force -Path $dir | Out-Null
& "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe" /nologo /out:"$dir\Claude.exe" Claude.cs

2. Create the registry entry the CLI uses for discovery:

$regPath = "HKCU:\Software\Microsoft\Windows\CurrentVersion\Uninstall\Claude"
New-Item -Path $regPath -Force | Out-Null
New-ItemProperty -Path $regPath -Name "DisplayName" -Value "Claude" -Force | Out-Null
New-ItemProperty -Path $regPath -Name "InstallLocation" -Value "$env:LOCALAPPDATA\Programs\claude-desktop" -Force | Out-Null

3. (Belt and braces) Add to user PATH:

$p = [Environment]::GetEnvironmentVariable("Path", "User")
[Environment]::SetEnvironmentVariable("Path", "$p;$env:LOCALAPPDATA\Programs\claude-desktop", "User")

Restart any open Claude Code sessions after this.

What this fixes

| Before | After |
|--------|-------|
| /desktop → "Failed to open Claude Desktop" | /desktop → session opens in Desktop app |
| Desktop app sidebar shows no active CLI sessions | Desktop discovers and displays active CLI sessions via Remote Control |

Why it works

The CLI checks for a Claude Desktop installation via filesystem paths and/or the Uninstall registry. The MSIX package creates neither. The shim executable simply forwards any arguments to the claude:// protocol handler that the MSIX package does register — so Windows routes it to the running Store app. This bridges the gap between the CLI's Win32-era discovery logic and the MSIX packaging model.

Regarding the upstream fix

+1 to the proposed ShellExecute fallback on claude://. The shim approach proves the protocol handler path works perfectly. The proper fix in the CLI should be:

1. Try existing Win32 path detection
2. If not found, check Get-AppxPackage -Name "Claude" or just attempt ShellExecute("claude://code/<sessionId>")
3. Only error if both fail

See also: #59883 (my independent report of the same issue, filed before finding this one)

Confirming this bug is still present on the latest Claude Code and Claude Desktop as of 2026-05-25 — over a week after #61194 was filed and auto-closed as a duplicate of this thread.

Environment

• OS: Windows 11 Home 10.0.26200
• Claude Code: 2.1.150 (native install)
• Claude Desktop: MSIX package Claude_1.8555.2.0_x64__pzs8sxrjxfjjc (installed via the .exe installer from https://claude.ai/download — which delivers as MSIX)
• Shell: PowerShell 7

Symptom
/desktop → Error: Failed to open Claude Desktop. Please try opening it manually.

Verified working alternatives on the same machine (so install + protocol handler are healthy, the CLI launcher is the broken piece):

• Start-Process "claude://" → opens the app
• Start-Process "shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude" → opens the app
• Start menu shortcut → opens the app

The MSIX-aware diagnosis in this issue still matches current behaviour exactly. The official installer at https://claude.ai/download continues to deliver Claude Desktop as an MSIX package, so every new Windows install hits this immediately on first /desktop.

Confirming on Windows 11 + adding a secondary finding

Environment

• Windows 11 Pro (26200)
• Claude Code CLI v2.1.169 (npm global install)
• Claude Desktop installed via MSIX/Store (from claude.ai/download)
• PackageFullName: Claude_1.11187.4.0_x64__pzs8sxrjxfjjc
• PackageFamilyName: Claude_pzs8sxrjxfjjc
• AUMID: Claude_pzs8sxrjxfjjc!Claude
• Install location: C:\Program Files\WindowsApps\Claude_1.11187.4.0_x64__pzs8sxrjxfjjc

/desktop returns:

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

Confirmed root cause (matches the issue): the launcher only resolves Win32
installs (%LocalAppData%\AnthropicClaude\app-*\claude.exe) and the classic
HKCR\claude\shell\open\command registry handler. An MSIX install has neither —
it lives in protected WindowsApps and registers a modern packaged protocol
handler instead.

Confirming this also affects installs from the official website installer, not only the Microsoft Store:

• Claude Code: 2.1.172
• Claude Desktop: 1.11847.5.0, installed 2026-06-10 via ClaudeSetup.exe (~6.7 MB bootstrapper) downloaded from claude.com/download
• Windows 11 Home 10.0.26100

Get-AppxPackage Claude shows SignatureKind: Developer — i.e. a sideloaded MSIX from the website bootstrapper, not a Store install. On this machine there is:

• no %LOCALAPPDATA%\AnthropicClaude directory (legacy Squirrel path),
• no claude.exe execution alias in %LOCALAPPDATA%\Microsoft\WindowsApps,
• no uninstall entry under HKCU/HKLM ...\CurrentVersion\Uninstall.

/desktop fails with "Failed to open Claude Desktop. Please try opening it manually."

Launching via AUMID works fine as a workaround:

explorer.exe shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude

Since the website installer now ships MSIX, this presumably affects all new Windows installs, not just Store users.

Still reproducing. Claude Code CLI v2.1.77, Claude Desktop MSIX package Claude_1.12603.1.0_x64__pzs8sxrjxfjjc (confirmed via Get-AppxPackage Claude), Windows. /desktop returns "Failed to open Claude Desktop. Please try opening it manually." despite the desktop app being installed and running. The claude:// protocol handler works correctly on this machine (Start-Process "claude://" launches the app), so the one-line ShellExecute("claude://...") fallback suggested in #59692 would resolve this. Adding a current-version data point since the prior reports were on earlier builds.

Still reproduces on current versions — confirming this is not fixed as of:

• Claude Code: 2.1.181
• Claude Desktop: Claude_1.14271.0.0_x64__pzs8sxrjxfjjc (MSIX / Microsoft Store)
• OS: Windows 11 Pro 10.0.26200
• Shell: PowerShell 7

/desktop fails with Error: Failed to open Claude Desktop. Please try opening it manually. —
both when typed manually in the TUI and when sent programmatically.

+1 — would really appreciate a fix or a timeline. Thanks!

Still repro on Claude Code 2.1.187 + Claude Desktop MSIX 1.15200.0.0 (Claude_…pzs8sxrjxfjjc, Get-AppxPackage status=Ok), Windows 10. Start-Process "claude://" and AUMID activation both work manually, but /desktop always fails with “Failed to open Claude Desktop.” A shim placed at %LOCALAPPDATA%\AnthropicClaude\app-X.X.X\claude.exe is never invoked, so even the Win32-path detection isn’t firing. The one-line ShellExecute("claude://") fallback would fix all MSIX installs.

Additional data point: the suggested cmd /c start fix is already shipping in 2.1.196 and still fails — root cause is the Bun child_process exit code

On current Claude Code (2.1.196, native/Bun build) the desktop handoff already does exactly what this issue suggested:

MOf(url): cmd /c start "" "claude://resume?session=<id>"   // success iff exitCode === 0

…and it still reports Failed to open Claude Desktop. I traced it with --debug-file:

[DEBUG] Opening deep link: claude://resume?session=<guid>

There is no following execFileNoThrow spawn failed line — i.e. the spawn does not throw. So cmd /c start "" "<url>" runs and returns a non-zero exit code under the Bun-compiled CLI, and MOf (which gates success on exitCode === 0) treats that as failure.

The exact same command returns exit 0 and successfully launches the app when run from any external shell — cmd, PowerShell, hidden window, piped stdio, with the project cwd, and via both MSIX protocol activation and a classic shell\open\command. I could not reproduce a non-zero exit anywhere outside the CLI's own child_process invocation. So start's exit code is simply not a reliable success signal here.

Install type is irrelevant. This reproduces on MSIX (my setup, Claude_pzs8sxrjxfjjc v1.15962.1) and on Squirrel/%LOCALAPPDATA%\AnthropicClaude (see #61194). Start-Process "claude://..." works in both. The bug is purely in how the launcher interprets the cmd /c start result.

Suggested fix: on Windows, don't gate success on the cmd /c start exit code. Options:

• call ShellExecuteEx/Start-Process on the claude:// URL directly and treat a non-throwing launch as success, or
• use explorer.exe "claude://...", or
• consider the handoff successful if the spawn didn't throw (drop the exitCode === 0 check for this code path).

Env: Claude Code 2.1.196 (native/Bun), Windows 11 Enterprise 10.0.26200, Claude Desktop MSIX v1.15962.1.

I'm hitting the same issue.

• Claude Code CLI version: 2.1.198
• Claude Desktop version: 1.17377.2 (e0ea9e), build date 2026-07-01T05:51:58.000Z
• Installation type: MSIX
• OS: Windows 11 Home, version 25H2, OS Build 26200.8737

Running /desktop fails with:
"Failed to open Claude Desktop. Please try opening it manually."

+1 for prioritizing a fix.