If you remember nothing else:
- The Microsoft Store opening on its own, days after a Claude install, is almost always a broken claude:// link handler, not malware.
- In a split-account setup (you log in as a standard user, a separate admin account answers the UAC prompt), the MSIX registers the handler under the admin profile, so your session has nothing to open claude:// links with.
- The fix is to remove the install and reinstall the signed MSIX machine-wide, or deploy it through Intune for a whole fleet.
You install Claude Desktop on a Windows 11 laptop. A few days pass. Then the Microsoft Store opens by itself. You didn’t click anything. You didn’t search for anything. You close the window, and an hour later it’s back.
This one looks like a mystery and isn’t. When a Claude product went on recently, the usual cause is a broken claude:// link handler. It shows up often enough that Anthropic has it logged in its own issue tracker. Once you see the chain of cause and effect, the fix takes about five minutes.
Two quick checks before you read on. Are you running Claude Desktop, the GUI app from claude.ai/download, rather than the Claude Code CLI? And did you install it on a machine where your day-to-day account is not an admin, typing separate admin credentials into the UAC prompt? If both are yes, what follows almost certainly applies to you.
Why the claude:// handler goes missing
When Windows can’t find an app to handle a custom link scheme, it shows a small dialog: “Get an app to open this ‘claude’ link. Your PC does not have an app that can open this link. Try looking for a compatible app in the Microsoft Store.” Search that exact phrase and you’ll find years of reports across dozens of unrelated apps. It’s generic Windows behavior, not anything specific to Claude.
What happens next is the confusing part. On Windows 10 the dialog usually waits for a click. On newer Windows 11 builds it can flash and dismiss on its own, and the Store window opens behind it. By the time you look up, the dialog is gone. You see the Store, with nothing on screen to explain it.
Anthropic logged the symptom in GitHub issue #28892, titled “Claude Desktop cannot install on Windows, redirects to Microsoft Store during installation.” The title says during install, but the same machinery fires any time after install when the handler is missing.
The reason it goes missing is in how the package registers. Claude Desktop ships as an MSIX, Microsoft’s modern app format, and that package registers the claude:// scheme so the OS knows to launch the app for those links. The registration is per user. That one detail is the whole problem.
Consider the standard enterprise setup. Your daily login is a standard user. When something needs admin rights, Windows shows a UAC prompt and you paste in a separate admin account. That’s the right pattern, and it’s what careful IT shops run. Now install Claude Desktop. The installer asks for elevation, you provide the admin credentials, and the elevated process registers the MSIX under the admin account, not under the daily login that started it. The app installs. It looks fine. But the claude:// handler lives in the admin profile, and your session has no claude key in its registry hive. Anything that fires a claude:// link finds no handler, and Windows offers the Store.
Anthropic has this documented end to end in issue #25055. The reporter’s own summary:
When the standard user later tries to use claude:// protocol, Windows cannot find the handler. Error message: “your computer does not have an app that can open this link.” This occurs because the protocol registration was made in the admin account’s registry hive, not the standard user’s.
If you installed Claude Desktop on a machine where your daily login is not an admin, that is almost certainly your situation.
What fires the link when you did not click anything
This is the part that trips people up. Nobody opens the Store. Nobody clicks a Claude link in a browser. The popup happens on its own.
A handful of ordinary things emit claude:// links with no visible action from you:
- Claude Desktop’s own background components, on launch or during an update check, sometimes fire a
claude://activation to bring the window forward or route a notification. - Windows runs default-app reconciliation passes after updates. If a registered scheme looks like it points at a missing handler, the OS can probe it.
- Notification clicks. If you ever tapped a Claude notification in the Action Center, Windows fires
claude://to open the right context. - Browser deep links, from anything you opened off claude.ai, an email, or a third-party tool that links into Claude.
- A leftover activation queued by a prior failed install. MSIX installs sometimes leave queue entries that fire days later.
You won’t see the trigger. You’ll only see the result.
How to fix it on one machine
If you have admin rights on your own machine, this is quick.
- Open PowerShell as your day-to-day user, no elevation. Run
Get-AppxPackage -Name "Claude" -AllUsers. If the status reads Ok and the package is registered against a different account than the one you’re logged in as, you’ve confirmed the diagnosis. - Open PowerShell as admin. Run
Get-AppxPackage -Name "*Claude*" -AllUsers | Remove-AppxPackage -AllUsers. That clears every Claude package from every profile. - Reboot.
- Download the signed MSIX straight from Anthropic’s deployment endpoint,
https://claude.ai/api/desktop/win32/x64/msix/latest/redirect. It serves the same package the regular installer would fetch, but you control where it lands. - From an elevated PowerShell, provision it machine-wide:
Add-AppxProvisionedPackage -Online -PackagePath "Claude.msix" -SkipLicense -Regions "all"That registers the package for every profile on the machine, so each user gets a clean per-user activation at next sign-in.
Sign back in as your daily user, open PowerShell, and run Start-Process "claude://test". Claude Desktop should come straight to the foreground with no shell dialog in between. If it does, the handler is fixed and the random Store popups stop. No admin rights on your machine? Send your IT team the next section.
How to fix it across a fleet
For managed machines, the clean move is to deploy the signed MSIX through Intune as a Line of Business app. That registers the handler correctly for every user, updates centrally, and sidesteps every flavor of the split-account problem. The same path covers Claude Desktop on a corporate network, where proxies and email gateways add their own friction.
Three things to know before you start.
The legacy Group Policy “Turn off the Store application” is deprecated on Windows 11 24H2. If your fleet runs 24H2 and you still lean on that GPO, your block may not actually hold. Microsoft’s recommended replacement is AppLocker or Windows Defender Application Control.
Blocking the Store interface and blocking Store installs are different controls, and neither one stops the popup. The Store window can still open when Windows fires its fallback dialog. Only fixing the handler makes that stop.
And watch for stale installs. Machines still on the old Squirrel-based build will not upgrade cleanly to the MSIX (issue #25162), and a half-migrated install is another way the handler ends up pointing nowhere. A clean uninstall and reinstall is the way out.
When it’s done right, three things are true. Claude Desktop shows in the Start menu, signed by Anthropic, PBC. A claude:// link launches the app instantly, with no Windows dialog in between. And the Store stays closed unless someone opens it on purpose.
What it is not
A few things get blamed for the same symptom.
It isn’t WSL. Claude Code runs natively on Windows 10 1809 and up, per the official setup docs, and the native install doesn’t touch the Store at all. That said, if someone ran wsl --install on Windows 11, that command does pull Ubuntu from the Store by default. Microsoft documents the —web-download flag specifically to skip that path. The tell there is a new Ubuntu icon in your Start menu, not anything Claude did.
It isn’t a virus. The Store opening, on its own, is not a malware signal. The protocol-handler explanation is far more boring, and it accounts for most of what gets reported.
It isn’t Edge. Progressive web apps surface an “App available” prompt inside the address bar. They don’t throw the Store window into the foreground without a click.
If a claude:// link launches the app with no Windows dialog in between, you’re done. The handler is registered where it belongs, and the popups have nowhere left to come from.
