Can't open this app: Claude Desktop won't start on Windows — fix it with Repair without losing your sessions

You try to open Claude Desktop on Windows and instead you get a dialog headed "Can't open this app", telling you that "You'll need to go to advanced options for Claude and select Repair" — and the good news is that doing exactly what it says works. No uninstall, and no Reset that throws your data away.

There is, however, one step in the middle where people actually get stuck. Clicking Repair can come back with a message telling you the app is still running — even though no Claude window is open anywhere. This article is built around getting past that step, and it also answers the question most people ask first: do your conversations and your Claude Code sessions survive this?

1. The short answer — Repair fixes it, but end the processes before you click it

Here is the whole procedure up front. Work down the list and stop as soon as it opens again. Each step costs more effort than the one above it, but not one of them loses your conversation history (see §3 for why).

2. The symptom — work out which dialog you are looking at

There is more than one way for Claude Desktop to fail to start on Windows, and each one needs a different fix. Get this wrong and you will burn an afternoon on remedies that were never going to work, so start by identifying the exact dialog in front of you.

This article covers the one that reads as follows.

✅ Confirmed: this is a standard Windows error screen for packaged (MSIX) apps, not something Claude produces. Which means the reverse is also true: if you are seeing this screen, you are on the MSIX build. Anthropic's Windows deployment documentation lists MSIX (x64 and arm64) as the distribution format.

Different wording means a different problem. If it says "Another program is currently using this file" (0x80070020), the fix is not Repair — it is signing out of Windows, which we cover in a separate article. A dialog reading "Claude Desktop failed to launch" is a third thing again; it is reported in GitHub #50285, which was closed without a resolution. §10 lays all of them out side by side.

3. Do your sessions get wiped? — three kinds, three answers

This is the first thing anyone in the middle of the problem wants to know. The short answer is that Repair deletes nothing. But "session" covers three different things stored in three different places, and the risk is different for each, so let us separate them.

✅ Confirmed: the row that matters is the second one. Claude Code's conversation logs pile up as .jsonl files under %USERPROFILE%\.claude\projects\, and that path sits directly in your user profile, not inside the app package. Repair the app, reset it, or uninstall it entirely — those files stay. Counting them on a real machine gave the following.

The third row, %APPDATA%\Claude, holds app-side settings such as window positions and cached sign-in state. Repair keeps it; Reset wipes it. Even that is recoverable by signing in again, but there is no reason to throw it away, which is one more argument for starting with Repair.

4. The procedure — diagnose, back up, repair

Run these in order. STEP 0 only reads, so it is safe.

STEP 0: check the current state (read-only)

Run this in an elevated PowerShell. It tells you what kind of broken you are dealing with.

Get-AppxPackage *laude* | Select-Object Name,PackageFullName,Version,InstallLocation,Status,IsPartiallyStaged | Format-List
Get-Service vmcompute,hns -ErrorAction SilentlyContinue | Select-Object Name,Status,StartType
Test-Path "$env:USERPROFILE\.claude\projects"

If Status reads Ok and the app still will not start, the likely state is a package that registered fine but has no working execution entry point (§7). If IsPartiallyStaged is True, staging finished half-done.

STEP 1: back up (before you touch anything)

Repair will not delete your data, but having a copy makes every later decision easier. Note that .claude can run to several gigabytes, so check your free space first.

$dst = "$env:USERPROFILE\Desktop\claude-backup-$(Get-Date -Format yyyyMMdd-HHmm)"
New-Item -ItemType Directory -Force $dst | Out-Null
robocopy "$env:USERPROFILE\.claude" "$dst\dot-claude" /E /R:1 /W:1 /NFL /NDL
robocopy "$env:APPDATA\Claude" "$dst\appdata-Claude" /E /R:1 /W:1 /NFL /NDL /XD Cache "Code Cache" GPUCache

The cache folders are excluded with /XD: they are large and none of them are needed to restore anything.

STEP 2: repair

Through the GUI, the route is this.

Settings → Apps → Installed apps → Claude → … (three dots) → Advanced options → Repair

✅ Confirmed: this sequence brought the app back on a real machine (Windows 11, July 2026). But the next section is the real subject of this article.

5. When Repair is refused because the app is still running

This is where people actually get stuck, and it is the reason this article exists.

You click Repair and you can get an error to the effect that it cannot run because the app is currently running. The maddening part is that there is no Claude window open anywhere. You closed it, and Windows still says no.

The fix is simple: explicitly end the processes, then click Repair. You can kill every Claude-related process from Task Manager, or use a single line in an elevated PowerShell.

Get-Process claude*,Cowork*,Anthropic* -ErrorAction SilentlyContinue | Stop-Process -Force

Click Repair straight after that and it goes through. ✅ Confirmed: this order recovered the app on a real machine, and the sessions were intact afterwards.

🟡 Reported: and the fact that a process was still holding those files points at the cause of the failure itself. §7 goes into it, but the outline is that the same process broke the update and then blocked the repair.

6. What to try next, in order, if it still will not open

If Repair does not bring it back, work through the following in order. Do not jump straight to a reinstall — you lose more and your odds do not necessarily improve.

6-1. Start the dependency services

Claude Desktop's sandboxing relies on Windows' virtualization stack. These services default to Manual start, so they can end up stopped after a reboot.

Start-Service vmcompute,hns -ErrorAction SilentlyContinue
Get-Service vmcompute,hns | Format-Table Name,Status,StartType

If the services do not exist at all, the corresponding Windows features are turned off. Enable them and reboot.

Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -NoRestart
Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform -NoRestart

6-2. Reinstall while keeping your data

The last resort. The important part is adding -PreserveApplicationData. Leave it off and the app-side data goes with it.

Get-Process claude*,Cowork*,Anthropic* -ErrorAction SilentlyContinue | Stop-Process -Force
Get-AppxPackage *laude* | Remove-AppxPackage -PreserveApplicationData
Restart-Computer

After the reboot, install it again from the official download page. If you need the MSIX directly — for an enterprise rollout, say — the distribution URLs are listed in the official documentation cited earlier.

7. Why it happens — a half-registered MSIX

🔴 Unconfirmed: to be clear from the outset, Anthropic has published no official explanation of this symptom. What follows is assembled from public issues and what was observed on a real machine.

MSIX does not work the way a classic installer does, dropping files into a folder. It registers the app with Windows as a package. On an update, the old package's registration is removed and the new one registered in its place.

The problem is that that de-registration cannot complete while something is holding the files open — and as §5 showed, Claude Desktop keeps running after you close its window. The result can be a halfway state in which the registration exists but there is nothing left to execute.

✅ Confirmed: this state has actually been reported. The reporter in GitHub #55465 documented an install that looked successful (Status: Ok, IsPartiallyStaged: False) yet produced neither an execution entry point nor a Start menu item. Trying to launch it made Windows open the Documents folder instead — the fallback behaviour when no entry point can be found.

That story also fits what was observed on the machine used here. Repair being refused on the grounds that the app was running means precisely that a process holding those files was still alive. Repair succeeding once the processes were killed is the corroboration.

8. Preventing a repeat

If the cause is "a process was holding files during an update", then the next update can do the same thing. There is no watertight prevention, but you can shorten the odds.

9. What about the old installer build?

Some Windows machines still run Claude Desktop from the installer format that predates MSIX (the Squirrel-style build). If %LOCALAPPDATA%\AnthropicClaude contains an Update.exe, that is what you have.

For this particular symptom, that format has a structural advantage. It never touches package registration: it lays down per-version folders such as app-1.24012.9 and swaps the launcher stub, so "half-registered" is not a failure mode it can have. The previous version's folder also stays around as a fallback, which helps.

So is it behind on features? ✅ Confirmed: the version numbers were identical, at least here.

On top of that, the logs on the old-format machine confirm it is still receiving updates. Hourly update checks were recorded through the day, and a new version was actually applied on July 25, 2026. There was no sign — at this point in time, at least — that "old format" means "old features".

10. Different problems that are easy to confuse with this one

These look alike but have different causes and different fixes. Use the wording of the dialog to tell them apart.

Summary

"Can't open this app" is fixed by doing what the dialog tells you and clicking Repair. You do not need the destructive "complete reset" routines that search results push at you.

The place people actually get stuck is Repair being blocked by a running process. Closing the window leaves the app resident in the tray, so clicking Repair while you think you have quit gets refused. End the processes explicitly first — that is all it takes. And the same process is, on the most consistent reading of the evidence, what broke the update in the first place.

As for your data: conversation history lives on the server, and Claude Code sessions live under your user profile, so neither Repair nor Reset can touch them. The only thing at risk is the app's own settings, and Repair keeps even that. Panicking into a reinstall costs you more than the bug does.

FAQ

Q1. What is the fastest fix?

Run Get-Process claude*,Cowork*,Anthropic* | Stop-Process -Force in an elevated PowerShell, then immediately go to Settings → Apps → Installed apps → Claude → Advanced options → Repair. No reboot and no uninstall required.

Q2. Will my sessions or conversation history be deleted?

Not by Repair. Your claude.ai conversation history sits on Anthropic's servers, and Claude Code sessions are stored in %USERPROFILE%\.claude\projects\, which is outside the app package. See the table in §3 for the full picture.

Q3. Is it all right to click Reset?

Not recommended. As the Windows screen itself says, "The app's data will be deleted" — meaning the app-side settings. Your conversation history and Claude Code sessions survive, so it is not fatal, but there is no reason to lose anything when Repair fixes the problem.

Q4. The window is closed, so why does Windows say the app is running?

Because Claude Desktop stays resident in the system tray after you close its window, and helper processes run as well. End every Claude-related process in Task Manager, or run the command in §5. This is the single most common sticking point with this bug.

Q5. Has Anthropic released an official fix?

Not as of July 28, 2026. The related GitHub issues (#55465, #50285, #48437) all ended "closed as not planned", and there is no official explanation of the cause either. The procedure in this article is the orthodox Windows package-management approach, not an official one.

Q6. Will it come back with every update?

If the cause is "a resident process holding files during an update", then it can recur whenever those conditions line up. It does not happen every time, though. Quitting explicitly from the tray when an update looks due lowers the odds (§8).

Q7. Should I switch to the old installer build?

Not recommended. The old format does have the advantage that "half-registered" cannot happen to it, but it is unclear whether you can still obtain it for a fresh install. And because a model's answer quality is decided server-side, changing the packaging format does not make it any smarter. See §9 for details.

Q8. I repaired it and the same screen came back.

Work through §6 in order. First check whether vmcompute and hns are running (they default to Manual start, so they may be stopped), and if that does not help, remove the package with Remove-AppxPackage -PreserveApplicationData so your data survives, then install it again. In that order you lose the least.

Related articles

• Claude Desktop will not start after an update (0x80070020) — for the "another program is currently using this file" case
• Claude Code "Connection closed mid-response" error — for when it starts fine but responses cut off partway