/desktop command fails on Windows Store (MSIX) installation

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/59692
2. https://github.com/anthropics/claude-code/issues/36079

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Update: Full Workaround Found

The shim approach fixes both /desktop AND the Desktop app's local session discovery (Remote Control showing CLI sessions in the sidebar).

Fix

Compile a minimal protocol-forwarding executable and place it where the CLI expects:

// Claude.cs
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 });
    }
}

Compile with .NET Framework (available on all Windows installs):

& "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe" /nologo /out:"$env:LOCALAPPDATA\Programs\claude-desktop\Claude.exe" Claude.cs

Then create the registry entry the CLI uses for discovery:

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

Why this works

The Claude Code CLI (and Desktop's LocalSessions discovery) look for a Claude Desktop installation via:

1. Known filesystem paths (%LOCALAPPDATA%\Programs\claude-desktop\Claude.exe)
2. Registry entries (HKCU:\...\Uninstall\Claude → InstallLocation)

The MSIX Store package doesn't create either of these. The 3KB shim executable just forwards to the claude:// protocol handler that the Store app DOES register, bridging the gap.

Additional finding

This also fixes the Desktop app's ability to discover and display active CLI sessions via Remote Control in the sidebar — not just the /desktop handoff command. The Desktop's local session trust check appears to depend on finding the CLI installation at a known path.

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.

Still reproducing on Claude Code v2.1.161 with the Microsoft Store (MSIX) Claude Desktop build, confirming this is still open. Adding the decompiled /desktop flow for the current CLI version plus some test data, in case it helps narrow the fix.

Environment

• OS: Windows 11 Pro 10.0.26200
• Claude Code (CLI): v2.1.161
• Claude Desktop: Microsoft Store (MSIX), Claude_<version>_x64__pzs8sxrjxfjjc, installed under C:\Program Files\WindowsApps\…, AUMID Claude_pzs8sxrjxfjjc!Claude
• No standalone install: %LOCALAPPDATA%\AnthropicClaude does not exist.
• Symptom: /desktop → Error: Failed to open Claude Desktop. Please try opening it manually.

Decompiled /desktop flow in v2.1.161 (Windows path)

The Windows path is a registry existence check + a claude:// deep-link launch (no exe-path lookup at launch time):

// install check
async function ueq() {            // win32 branch
  let { code } = await p6("reg", ["query", "HKEY_CLASSES_ROOT\\claude", "/ve"]);
  return code === 0;
}

// version check — reads %LOCALAPPDATA%\AnthropicClaude\app-* for a version
async function C55() {
  let $ = path.join(process.env.LOCALAPPDATA, "AnthropicClaude");
  try { return (await readdir($)).filter(f => f.startsWith("app-"))... } catch { return null }
}

async function meq() {
  if (!await ueq()) return { status: "not-installed" };
  let q; try { q = await C55() } catch { return { status: "ready", version: "unknown" } }
  if (!q) return { status: "ready", version: "unknown" };          // <- MSIX hits this (folder absent)
  let v = coerce(q);
  if (!v || !satisfies(v, "1.1.9669")) return { status: "version-too-old", version: q };
  return { status: "ready", version: q };
}

// build deep link: claude://resume?session=<sessionId>
function I55(session) { let u = new URL("claude://resume"); u.searchParams.set("session", session); return u.toString(); }

// launch
async function b55(H) {
  N(`Opening deep link: ${H}`);
  let { code } = await p6("cmd", ["/c", "start", "", H]);
  return code === 0;
}

async function kI_() {
  let session = N8();
  let q = await meq();
  if (q.status === "not-installed")  return { success:false, error:"Claude Desktop is not installed. Install it from https://claude.ai/download" };
  if (q.status === "version-too-old") return { success:false, error:`Claude Desktop ${q.version} is too old…` };
  let link = I55(session);
  if (!await b55(link)) return { success:false, error:"Failed to open Claude Desktop. Please try opening it manually.", deepLinkUrl: link };
  return { success:true, deepLinkUrl: link };
}

So on a Store install: ueq() passes (the bare HKCR\claude URL Protocol stub exists), and C55() returns null (no %LOCALAPPDATA%\AnthropicClaude), so meq() returns {status:"ready", version:"unknown"} and the version gate is skipped. Execution reaches b55(), whose success is solely code === 0 from cmd /c start "" "<deep link>".

Test data (manual reproduction of b55's launch)

On the same machine, with Desktop fully closed each time:

| Command | Exit | Result |
|---|---|---|
| Start-Process "claude://" | 0 | Desktop launches |
| Start-Process "claude://resume?session=<GUID>" | 0 | Desktop launches |
| cmd /c start "" "claude://resume?session=<GUID>" (exact b55 form) | 0 | Desktop launches |

i.e. the claude:// protocol activation works for the MSIX build (consistent with @Baouse's report above), and b55's exact command returns exit 0 and opens the app when run by hand. Yet /desktop from inside the CLI still reports failure. So the failing step is not the protocol itself — b55 ought to return true here, which points at the launch happening in a different runtime context inside the CLI (the detached session/daemon process) where the cmd spawn returns non-zero, or at an earlier discovery step than the one in this decompiled path.

This lines up with @jbk1998's diagnosis that the CLI (and Desktop's local-session discovery) expect a Claude Desktop install at a known path / HKCU\…\Uninstall\Claude InstallLocation, neither of which the MSIX package creates — and that the shim + registry entry fixes both /desktop and the sidebar session discovery.

Suggested fix (CLI side)

• Detect MSIX installs (Get-AppxPackage -Name Claude) and activate via AUMID (Claude_pzs8sxrjxfjjc!Claude) when the standard path/registry discovery fails, instead of reporting a hard failure.
• When b55 reports a non-zero exit but the claude:// protocol resolves to a packaged handler, fall back to AUMID activation rather than surfacing "Failed to open."

Happy to provide more of the decompiled trace or run additional diagnostics if useful.

Root cause isn't path detection - the install/version check passes (I get "Failed to open", not "not installed"). It's the opener: the claude:// deep link has multiple query params joined by &, and it's opened via spawnSync('cmd', ['/c','start','',url]).

cmd.exe treats & as a command separator (argv quoting doesn't escape it), so the URL is split, the tail runs as bogus commands, and cmd exits 1 → "Failed to open".

Repro:

const { spawnSync } = require('child_process');
const run = u => spawnSync('cmd', ['/c','start','',u]).status;
run('claude://x?a=1');        // 0
run('claude://x?a=1&b=2');    // 1  ('b' is not recognized...)
run('claude://x?a=1^&b=2');   // 0

Note: the MSIX app already handles claude:// natively, so the registry-shim workarounds don't help - start breaks on & before the URL is ever dispatched.

Fix: open the URL without cmd parsing - e.g. rundll32 url,OpenURL <url> (already used elsewhere in the codebase for browser links) or ShellExecute, or just escape &. Same diagnosis as #26197, which was stale-closed without a fix.

Confirming this is still broken on the latest version.

Claude Code: 2.1.162 (native install)
Claude Desktop: MSIX / Microsoft Store install — package family Claude_pzs8sxrjxfjjc (AppUserModelID Claude_pzs8sxrjxfjjc!Claude)
OS: Windows 11
Shell: Windows Terminal (PowerShell)

/desktop fails with "Failed to open Claude Desktop. Please try opening it manually." every time, even when Claude Desktop is already installed, running, and opens fine manually. It fails at the launch/detection step, so the session is never handed off.
Ruled out on my machine: outdated CLI (on latest 2.1.162), broken Desktop (launches fine), and AV/EDR interference (0 interceptions, nothing blocked).
The Win32 path detection misses MSIX installs. A fallback to the registered claude:// protocol handler (ShellExecute / Start-Process "claude://...") would fix it for Store installs.

Reproducible on my setup as well — adding diagnostics that may help narrow it down.

Environment:

• Claude Code CLI 2.1.198, Windows 11 Pro (build 26200)
• Desktop app installed as MSIX: Claude_1.17377.2.0_x64__pzs8sxrjxfjjc (InstallLocation under C:\Program Files\WindowsApps)
• Notably, the installer downloaded from claude.com delivers the same MSIX package — after uninstall + reinstall from the website, Get-AppxPackage shows the identical PackageFullName, so there is no non-MSIX install path to fall back to on this machine.

Symptoms:

• /desktop always fails with Failed to open Claude Desktop. Please try opening it manually. — including when the desktop app is already running.

What does work (potential fix directions):

• URI activation: Start-Process "claude://" launches/foregrounds the app fine
• Shell activation: explorer.exe shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude works too
• HKCU:\Software\Classes\claude exists but has no shell\open\command (URI activation is handled by the MSIX manifest, not the classic registry command) — if the CLI resolves the handler via the registry command or a hardcoded exe path, that would explain the failure
• claude-cli:// maps to %USERPROFILE%\.local\bin\claude.exe --handle-uri "%1" as expected

Falling back to ShellExecute on the claude:// URI (letting Windows route it through MSIX URI activation) would likely fix this for Store/MSIX installs.