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

Jayanth Artham — Fri, 07 Aug 2026 20:14:17 +0000

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 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.
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>"

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

DEV Community: Jayanth Artham