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)
(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"
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:
-
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. -
Version gate — it lists
%LOCALAPPDATA%\AnthropicClaude\and parsesapp-X.Y.Zsubfolder 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 protectedC:\Program Files\WindowsApps\directory instead. Missing or too-old folder → blocked. -
Launch —
cmd /c start "" claude://resume?session=<sessionId>, i.e. the plainclaude://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>"
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
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
Top comments (1)
This is the kind of small platform-specific failure that deserves a clear diagnostic path. The error sounds like a missing app, but the real issue is often install location, package identity, or the bridge the CLI expects. A good fix is not just a workaround; it is making the detection explain which assumption failed.