Claude Desktop Won’t Install on Windows? Here’s the Real Fix

I spent an evening last month trying to get Claude desktop Windows install working on a Windows 11 Pro machine that, by every reasonable measure, should’ve handled it fine. It didn’t. The installer kept bouncing between “administrator access required” and a silent failure with no real explanation. So if you’ve landed here mid-troubleshooting, you’re not imagining things — this is a known mess, and most of it traces back to one packaging change Anthropic made earlier this year.

Quick Answer

If you just want the short version before reading the whole thing:

• Most install failures are MSIX permission or sideloading errors, not corrupted downloads
• Enable Developer Mode (or at minimum allow sideloaded apps) in Windows Settings before reinstalling
• If a previous version is “stuck,” remove it with PowerShell’s Remove-AppxPackage -AllUsers before trying again
• Cowork specifically needs Windows Pro/Enterprise with Hyper-V — Home edition can install Claude but not Cowork
• When nothing else works, grab the MSIX package directly and install it manually instead of using the bootstrapper

None of these are exotic fixes. They’re just not where Windows points you first.

Why It Fails

Claude Desktop on Windows switched from a Squirrel-based .exe installer to Microsoft’s MSIX packaging format earlier this year, around the same time Cowork shipped. That move is the root of basically every install headache people are running into now. A few specific things go wrong:

Sideloading isn’t enabled. MSIX apps installed outside the Microsoft Store need either a trusted signing certificate or “Trusted App Installs” turned on, which lives under Developer Mode in Windows Settings. The old .exe installer never needed this. The new one does, and nothing in the install flow tells you that clearly — you just get a popup about the Microsoft Store not having a compatible app, which is about as unhelpful an error message as Windows produces.

A previous install is stuck in a half-registered state. This is the one that burned the most time for me. If an update interrupts, or a previous uninstall didn’t fully complete, the MSIX package can end up “Staged” or partially registered — visible to Get-AppxPackage but impossible to cleanly remove or reinstall over. You’ll see HRESULT codes like 0x80073CFA (can’t remove) paired with 0x80073D28 or 0x80073CF6 (can’t install), and they tend to show up together.

Cowork’s VM service conflicts with something already running. Cowork needs Hyper-V, and it installs a service called CoworkVMService. If that service already exists in a weird state — left over from a previous install attempt, or blocked by antivirus or a Group Policy — the installer throws “Administrator access is required” even when you already ran it as admin. That message is genuinely misleading, by the way. The real cause is usually an access-denied error on the service handle, not a missing permission.

And there’s a fourth cause that’s easy to miss: a network or proxy issue mid-download that corrupts the installer package itself, which produces a generic “download failed” error with no useful detail. From what I’ve seen, this one’s less common than the permission issues, but it does happen on corporate networks with aggressive content filtering.

Common Scenarios

Worth noting: ARM64 Windows devices are supported now too, but it’s a newer addition and some people report instability there that you won’t see on x64.

Step-by-Step Fixes

Step 1: Check Windows edition and architecture first

Before touching the installer, confirm you’re not chasing a permissions problem that’s actually an edition limitation. Open Settings > System > About and check your edition and system type.

• Claude Desktop itself runs on Windows 10/11, x64 (and now ARM64, though that’s newer and a little rough around the edges)
• Cowork specifically requires Pro, Enterprise, or Education — Home edition lacks Hyper-V, so Cowork won’t install no matter what you do. Chat still works fine on Home.

If you’re on Home and just want the assistant itself, skip every Cowork-related fix below — they won’t apply to you.

Step 2: Enable sideloading / Developer Mode

This solves the single most common cause.

1. Open Settings > Privacy & Security > For Developers
2. Turn on Developer Mode (or just “Install apps from any source, including loose files” if that’s the only toggle you see — Windows has changed this UI more than once)
3. Restart the installer

I’ll be honest, this feels backwards — you’re enabling a developer-facing setting just to install a chat app. But that’s how MSIX sideloading works outside the Store, and it’s not specific to Claude.

Step 3: Clear out a stuck previous install

If you’ve already tried installing and hit a wall, there’s a decent chance a half-registered package is blocking you. Open PowerShell as Administrator and run:

powershell

Get-AppxPackage -Name "*Claude*" -AllUsers

If something shows up, remove it:

powershell

Get-AppxPackage -Name "*Claude*" -AllUsers | Remove-AppxPackage -AllUsers

That command fails sometimes too — if it does, a reboot before retrying clears a surprising number of these “ghost lock” situations. Not 100% sure why a restart fixes what a direct removal command can’t, but it’s consistent enough that I do it by default now.

Step 4: Run the installer as Administrator, explicitly

Right-click ClaudeSetup.exe and choose “Run as administrator” rather than just double-clicking and accepting the UAC prompt. This matters more than it should — there’s a known issue where providing admin credentials through a UAC prompt as a standard user installs the package under the Administrator profile instead of yours, which then blocks your own account from installing it afterward.

Step 5: If Cowork specifically won’t install, check the VM service

Claude installs but Cowork doesn’t, and the error mentions HRESULT 0x80073CF6 or an “Administrator access is required” message despite already being elevated? Open Services (services.msc) and look for CoworkVMService. If it exists but shows as stopped or in an odd state, stop and delete it manually, then reinstall:

powershell

sc.exe stop CoworkVMService
sc.exe delete CoworkVMService

Then run the installer again. This fixed it for a few people who’d already tried everything else, including a full uninstall/reinstall cycle that didn’t touch the orphaned service.

Step 6: Manual MSIX install as a last resort

If the bootstrapper keeps failing and you’ve ruled out the permission and stuck-package issues, you can skip the installer entirely and install the MSIX package directly. This is a known workaround, not an official method, so treat it that way:

1. Download the .msix package directly rather than the Setup.exe bootstrapper
2. Open PowerShell as Administrator
3. Run Add-AppxPackage -Path "C:\path\to\Claude.msix"

The resulting install is the same app and still gets automatic updates afterward — it’s just bypassing a bootstrapper that, for whatever reason, isn’t completing the download or handoff cleanly on your machine.

What Actually Worked For Me

My case ended up being the stuck-package one. First reinstall attempt threw 0x80073CF6, so I assumed it was a permissions thing and spent close to an hour fiddling with UAC settings and Developer Mode toggles. That wasn’t it — both were already correct.

What actually fixed it was almost an accident. I rebooted out of frustration more than strategy, ran Get-AppxPackage -Name "*Claude*" -AllUsers afterward mostly to confirm the mess was still there, and the previous broken package was gone. A clean install went through on the next try with zero issues. So the reboot apparently cleared something the removal command alone couldn’t touch — some kind of file lock or deployment service hang, going by what other people have reported with the same error pair. I got a little lucky there, honestly; I’d half-expected to be filing a support ticket by that point.

Advanced Fixes and Edge Cases

Check the install log directly. Every install attempt writes a log to %TEMP%\ClaudeSetup.log (or a similarly named temp file — the exact path showed up differently for me between attempts). It’s more informative than the dialog box, which tends to show a generic message even when the log has the real underlying error code right there. If you’re going to ask anyone for help with this, that log is what they’ll actually want.

Look at Event Viewer for AppX Deployment errors. Under Windows Logs > Application, filter for source “Microsoft-Windows-AppXDeploymentServer.” This is where you’ll see the actual deployment failure reason rather than the simplified message the installer shows. Useful when the installer error code doesn’t match what’s logged — that mismatch happens more than you’d expect.

Group Policy can block sideloading even with Developer Mode on, particularly on company-managed laptops. If Developer Mode is enabled but installs still get blocked by “IT policy,” that’s a Group Policy or MDM restriction overriding the local setting, and no amount of local troubleshooting will get around it — you need IT to allow sideloaded/unsigned app installs at the policy level.

EditionID misdetection on LTSC builds. There’s a known issue on some Windows 10 IoT Enterprise LTSC systems where the installer incorrectly claims “Windows S Mode must be disabled,” even though S Mode isn’t actually on. It’s misreading the edition string. If you’re on an LTSC build and get that message, it’s very likely a false positive rather than an actual S Mode restriction.

Prevention Tips

• Before any major Claude Desktop update, check whether a previous version cleanly uninstalled — don’t assume it did
• On managed/corporate machines, talk to IT about sideloading policy before you hit the wall, not after
• If you’re on Windows Home and need Cowork, that’s an OS edition limitation, not a bug — upgrading to Pro is the only real fix
• Keep the install log location handy; if something breaks again, you’ll want it immediately instead of hunting for it under pressure
• Don’t run the installer multiple times back-to-back hoping it resolves itself — that’s actually how packages end up in the half-registered “Staged” state in the first place

FAQ

Why does Claude Desktop ask for admin rights when it didn’t before? Because of the MSIX packaging switch. The old .exe installer didn’t need elevated permissions for a standard install; the MSIX format generally does, especially for the Cowork component.

Is it safe to enable Developer Mode just to install this? Yes. Developer Mode mainly affects what’s allowed to be installed from outside the Store — it doesn’t weaken your account permissions or expose anything by itself. You can turn it back off after installing if you’d rather not leave it on.

My antivirus might be blocking the install — is that a real possibility? It’s possible, particularly with the CoworkVMService conflicts. Some endpoint security tools flag new system services aggressively. Worth temporarily checking your AV logs around the install timestamp if other fixes don’t work.

Will reinstalling delete my chat history? No, your conversations are tied to your account, not the local install. A reinstall just resets the local app package.

Does this affect Mac too? No — this is a Windows-specific packaging issue. The Mac installer uses a different format entirely and isn’t affected by any of this.

Editor’s Opinion

honestly this whole mess is a packaging migration problem more than anything wrong with your PC. the error messages just don’t tell you that, so people burn hours assuming it’s their machine. if Developer Mode + clearing a stuck package doesn’t fix it, the manual MSIX install basically always does — it’s not elegant but it works. your mileage may vary depending on what state your install got left in.