Fixing Claude Code's /desktop on Windows: "Claude Desktop is not installed" (Microsoft Store/MSIX installs)

If you use the Claude Code CLI on Windows and type /desktop to hand your session to the Claude Desktop app, you may hit this — even while Claude Desktop is literally open on your screen:

Claude Desktop is not installed.
Download now? (y/n)

Enter fullscreen mode Exit fullscreen mode

(Or on some versions: Failed to open Claude Desktop. Please try opening it manually.)

Answering y just re-downloads the same package you already have. Here’s the actual cause, and a fix that takes one folder.

Who this affects

Anyone on Windows with Claude Desktop installed as the Microsoft Store / MSIX package — which is what claude.ai/download delivers on Windows today. Verified on CLI 2.1.224 with Desktop package 1.26832.0.0.

TL;DR — the fix

# 1) Confirm the registry key the CLI checks (MSIX installs have it):
reg query HKEY_CLASSES_ROOT\claude /ve

# 2) Get your installed Desktop version:
Get-AppxPackage -Name "Claude" | Select-Object -ExpandProperty Version

# 3) Create the version folder the CLI reads — use YOUR version from step 2:
New-Item -ItemType Directory -Force -Path "$env:LOCALAPPDATA\AnthropicClaude\app-1.26832.0.0"

Enter fullscreen mode Exit fullscreen mode

Close the terminal, open a fresh one, claude --resume, pick a session, /desktop — it opens in the Desktop app with the full conversation.

Why this happens

On Windows, /desktop in CLI 2.1.224 does exactly three things:

1. Detection — one registry query: reg query HKEY_CLASSES_ROOT\claude /ve (exit 0 = installed). Nothing else. The MSIX package registers this key, so detection passes.
2. Version gate — it lists %LOCALAPPDATA%\AnthropicClaude\ and parses app-X.Y.Z subfolder names as the Desktop version, requiring at least 1.1.9669. This folder layout comes from the old Win32 (Squirrel) installer. MSIX installs never create it — the app’s real binary lives under the protected C:\Program Files\WindowsApps\ directory instead. Missing or too-old folder → blocked.
3. Launch — cmd /c start "" claude://resume?session=<sessionId>, i.e. the plain claude:// protocol, which the Store app handles perfectly.

So the pipe was never broken — the CLI is checking a version signal from an installer format Anthropic no longer ships. Creating the folder with your real version satisfies the gate, and everything downstream just works.

Bonus: the deep-link format

That launch step reveals something useful — you can hand any saved session to the Desktop app without the CLI:

Start-Process "claude://resume?session=<sessionId>"

Enter fullscreen mode Exit fullscreen mode

Session IDs are the .jsonl filenames under %USERPROFILE%\.claude\projects\<encoded-project-path>\.

How I found this

The known workaround (a shim exe + an Uninstall registry key, from this GitHub comment — credit to its author) was written against CLI 2.1.143 and no longer worked on 2.1.224. So I asked Claude Code to inspect its own installed binary and report exactly what the /desktop path checks. It came back with the registry key, the version-folder gate and its minimum constant, and the launch command — everything above.

Undo

Remove-Item "$env:LOCALAPPDATA\AnthropicClaude" -Recurse -Force

Enter fullscreen mode Exit fullscreen mode

Caveats

Verified on my machine only (Windows 11 x64, CLI 2.1.224, Store Desktop 1.26832.0.0). These are internal details and they clearly move between releases — the older workaround breaking is the proof — so date-stamp your expectations. Hopefully Anthropic ships the proper fix (fall back to ShellExecute("claude://...") and read the MSIX version via Get-AppxPackage); the open issue is anthropics/claude-code#59692, where I’ve posted these findings: https://github.com/anthropics/claude-code/issues/59692#issuecomment-5221532326