[BUG] Reopening of Claude Desktop Installation Fails on Windows 11 - Signature Verification & Unable to Load #25385

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/25162
2. https://github.com/anthropics/claude-code/issues/25194
3. https://github.com/anthropics/claude-code/issues/25313

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Adding a related but distinct symptom: OAuth token immediately cleared on startup (v1.1.3363, MSIX, enterprise)

Environment:

OS: Windows 11 Pro 10.0.26200 (enterprise-managed via Intune)
Claude Desktop: v1.1.3363 (MSIX / Windows Store package: Claude_pzs8sxrjxfjjc)
Previous working version: v1.1.3189
Developer Mode: disabled via policy (same constraint as OP)
Symptom:
Claude Desktop launches briefly, shows the splash screen, then crashes in a loop. No error dialog — the window simply disappears within a few seconds.

Root cause found in logs:

In %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\main.log:

[oauth] obtained new token
[growthbook] refreshing feature flags
[oauth] clearing token cache
The OAuth token is acquired successfully, but immediately cleared by a Growthbook feature flag refresh — causing a login loop. Claude never completes initialization.

Additional errors in unknown-window.log:

TypeError: Failed to fetch (https://claude.ai/...)
TypeError: Cannot read properties of undefined
What I tried (none resolved the issue):

Removed stale MCP server config entries
Cleared LocalCache\Roaming\Claude (keeping claude_desktop_config.json)
Uninstalled and reinstalled via the Store
Created a directory junction to work around path issues with Japanese characters + parentheses in %USERPROFILE%
Notes:

The previous version (1.1.3189) worked fine on the same machine
The path C:\Users\[username with Japanese chars + parentheses]\AppData\... may interact with the MSIX LocalCache path resolution, though this appears secondary to the OAuth/Growthbook race condition
Looks like this is a different failure mode from the "Trusted app installs" error in the OP, but likely related to the same MSIX transition regression introduced around the Cowork release. Happy to provide full logs if helpful.

I’m seeing the same regression on our Windows 11 25H2 fleet. The 1.0.0.0 installer is indeed triggering the ‘Trusted App’ requirement because it's failing the MSIX trust chain validation in managed environments where sideloading is blocked via GPO/Intune.

For IT Admins who can't enable Developer Mode, a verified workaround to get the 1.0.0.0 build installed is to manually inject the Anthropic certificate into the Trusted People store via PowerShell as Admin:

PowerShell

# Extract and Trust the Certificate (Run as Admin)
$certPath = "C:\Path\To\ClaudeSetup.exe"
$cert = (Get-AuthenticodeSignature -FilePath $certPath).SignerCertificate
$store = New-Object System.Security.Cryptography.X509Certificates.X509Store("TrustedPeople", "LocalMachine")
$store.Open("ReadWrite")
$store.Add($cert)
$store.Close()

Once the cert is in TrustedPeople, the installer should bypass the 'Developer Mode' prompt.

I've documented a deeper roadmap for these enterprise-managed workarounds and governance frameworks in the repository and website link on my profile. Hopefully, we get an official signed MSI soon so we don't have to rely on manual cert injections.

Update (follow-up to my previous comment):

After further investigation, I found a second distinct failure mode affecting my machine — different from the OAuth token race condition I reported earlier.

New symptom: Claude exits immediately on launch, before creating any user data directory or log files. No WER crash reports, no Application event log errors — just a clean exit within seconds.

Root cause: Exit code -529697949 (0xE06D7363 = unhandled C++ exception in the Electron/native layer). The crash occurs before Electron initializes the userData path.

Trigger: My Windows username contains Japanese characters and parentheses: userName(include Japanese). The MSIX version's native path-handling code throws an unhandled C++ exception when attempting to create the user data directory under this path:

C:\Users\userName(include Japanese)\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude
Why it was intermittent: The crash only occurs when the data directory needs to be created for the first time. If the directory already exists (e.g., from a previous install), Claude launches successfully. After a reinstall/reset cycle that wipes the LocalCache, the directory creation fails and Claude never starts.

Confirmed workaround: Launch Claude.exe directly with --user-data-dir pointing to an ASCII-only path:

& "C:\Program Files\WindowsApps\Claude_1.1.3363.0_x64__pzs8sxrjxfjjc\app\Claude.exe" --user-data-dir=C:\ClaudeData
Claude starts and runs normally with this flag. This is a desktop shortcut workaround — not sustainable long-term since the path changes with each version update.

Environment: Windows 11 Pro 10.0.26200, v1.1.3363 (MSIX), enterprise-managed (Intune), Japanese locale with non-ASCII username containing parentheses.

This appears to be a separate bug from the Trusted App installation issue in the OP, but likely shares the same MSIX transition root. Happy to provide additional logs if helpful.

same exit issues as above no user data created,
windows 10 pro version 10.0.19045 build 19045
i have turned on trusted app and still having the same issues when trying to reinstall for cowork features.

I’m seeing the same regression on our Windows 11 25H2 fleet. The 1.0.0.0 installer is indeed triggering the ‘Trusted App’ requirement because it's failing the MSIX trust chain validation in managed environments where sideloading is blocked via GPO/Intune.

I've documented a deeper roadmap for these enterprise-managed workarounds and governance frameworks in the repository and website link on my profile. Hopefully, we get an official signed MSI soon so we don't have to rely on manual cert injections.

Thx here is what worked for me based on your tip. I need to enable dev mode, then disable.

### Claude Desktop Silent Installer
### Run as Administrator

$certPath = "C:\working1\Claude Setup.exe"
$appxKey = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock"

### Step 1: Import cert
Write-Host "Importing certificate..." -ForegroundColor Cyan
$cert = (Get-AuthenticodeSignature -FilePath $certPath).SignerCertificate
$store = New-Object System.Security.Cryptography.X509Certificates.X509Store("TrustedPeople", "LocalMachine")
$store.Open("ReadWrite")
$store.Add($cert)
$store.Close()

### Step 2: Set registry keys
Write-Host "Setting registry keys..." -ForegroundColor Cyan
Set-ItemProperty -Path $appxKey -Name "AllowAllTrustedApps" -Value 1 -Type DWord
Set-ItemProperty -Path $appxKey -Name "AllowDevelopmentWithoutDevLicense" -Value 1 -Type DWord

### Step 3: Install
Write-Host "Running installer..." -ForegroundColor Cyan
Start-Process -FilePath $certPath -Wait

### Step 4: Revert - leave AllowAllTrustedApps=1, disable DevMode
Write-Host "Reverting registry..." -ForegroundColor Cyan
Set-ItemProperty -Path $appxKey -Name "AllowDevelopmentWithoutDevLicense" -Value 0 -Type DWord

### Step 5: Verify final state
Write-Host "`nFinal registry state:" -ForegroundColor Green
Get-ItemProperty $appxKey | Select-Object AllowAllTrustedApps, AllowDevelopmentWithoutDevLicense

This is still happening with the latest Claude Setup download from https://claude.ai/downloads as of Mar. 2nd (Windows 11).

Also just had this today, March 2nd with Windows 11. An application like this should never need "developer" tools bypass to install and I also should not need to inject certificates to get it to function.

This is an echo of malware, not of an enterprise tool.

I'm seeing that error on Mac using the latest mac download

Same issue here. Windows 11. Source: https://claude.com/download?open_in_browser=1. I tried it multiple times across the day. The installer without "cowork" installed without any issues.

<img width="1478" height="469" alt="Image" src="https://github.com/user-attachments/assets/b68c2a2a-bd20-44ab-9d13-794c93b9e2a2" />

Funny story. The exe on their website downloads an MSIX package.

https://api.anthropic.com/api/desktop/win32/x64/msix/latest/redirect

I'm going to try and push via Intune now and see what happens

Updating via winget upgrade Anthropic.Claude also fails:

<img width="690" height="375" alt="Image" src="https://github.com/user-attachments/assets/fd5d09a5-990c-467c-bd38-5b04cef8b511" />

Yeah so intune was a bust but I was able to install the app without enabling developer mode by running the MSIX package.

It requested Admin permissions and installed with no problems

https://api.anthropic.com/api/desktop/win32/x64/msix/latest/redirect

@TechManManManManManManMan That worked perfectly!

@TechManManManManManManMan Thanks! Could you explain where to find the download link you posted please?

I found it in the output log that generated when I tried to install the exe.

Log file: C:\Users\USRNM~1\AppData\Local\Temp\ClaudeSetup.log

<img width="1651" height="589" alt="Image" src="https://github.com/user-attachments/assets/c6be26e9-93fd-4b28-a773-1180160de568" />

Thanks @TechManManManManManManMan, my log doesn't include this, it doesn't even start downloading or so:

...
2026/03/17 13:25:43.479106 Log file: C:\Users\USER~1\AppData\Local\Temp\ClaudeSetup.log
2026/03/17 13:25:43.479627 === Claude Setup started ===
2026/03/17 13:25:43.481258 Windows edition: Professional
2026/03/17 13:25:43.481838 Windows version: 10.0.26200
2026/03/17 13:25:43.481838 Native arch: x64
2026/03/17 13:25:43.481838 Elevation type: Full
2026/03/17 13:25:43.481838 Is elevated: true
2026/03/17 13:25:43.481838 Sideloading enabled: false
2026/03/17 13:25:43.481838 S Mode: false
2026/03/17 13:25:43.481838 Conflicting service: false
2026/03/17 13:25:43.481838 Running in non-elevated context
2026/03/17 13:25:43.481838 Prerequisite check failed: trusted app installs are not enabled
2026/03/17 13:25:43.481838 ERROR dialog: trusted app installs not enabled
2026/03/17 13:25:44.570069 Opening ms-settings:developers 

I guess im cool and lucky like that lol :)

It makes me wonder why Anthropic Didn't just link to the signed MSIX and/or publish it to the Microsoft Store instead of wrapping it in this faulty installer.

Is Anthropic deliberately discriminating against Windows users? I can't believe they can't fix this bug or don't even try to. The solution should be easy.

+1 on this. My Claude from https://claude.com/download?open_in_browser=1 install corectly,

But Cowork still says "Cowork requires a newer installation"...

<img width="587" height="127" alt="Image" src="https://github.com/user-attachments/assets/5825be28-748e-40c0-b037-6befbf41e738" />

Here's my install log:

2026/03/26 10:30:35.553994 Log file: C:\Users\***\AppData\Local\Temp\ClaudeSetup.log
2026/03/26 10:30:35.555147 === Claude Setup started ===
2026/03/26 10:30:35.555710 AllowDevelopmentWithoutDevLicense found with value: 1
2026/03/26 10:30:35.555710 Windows edition: Enterprise
2026/03/26 10:30:35.556824 Windows version: 10.0.26200
2026/03/26 10:30:35.556824 Native arch: x64
2026/03/26 10:30:35.556824 Elevation type: Full
2026/03/26 10:30:35.556824 Is elevated: true
2026/03/26 10:30:35.556824 Sideloading enabled: true
2026/03/26 10:30:35.556824 S Mode: false
2026/03/26 10:30:35.556824 Conflicting service: false
2026/03/26 10:30:35.556824 Running in non-elevated context
2026/03/26 10:30:35.556824 User can elevate — installing MSIX directly
2026/03/26 10:30:35.577582 Splash: 400x300, 8 frame(s), animated=true
2026/03/26 10:30:35.578132 System DPI: 144 (scale: 150%)
2026/03/26 10:30:35.664028 MSIX URL: https://api.anthropic.com/api/desktop/win32/x64/msix/latest/redirect
2026/03/26 10:30:35.667275 Downloading MSIX to C:\Users\*\AppData\Local\Temp\Claude-278047894.msix
2026/03/26 10:30:36.218641 Download progress: 10% (17088384 / 170786079 bytes)
2026/03/26 10:30:36.675484 Download progress: 20% (34176768 / 170786079 bytes)
2026/03/26 10:30:36.856972 Download progress: 30% (51248768 / 170786079 bytes)
2026/03/26 10:30:37.164752 Download progress: 40% (68320192 / 170786079 bytes)
2026/03/26 10:30:37.372090 Download progress: 50% (85408576 / 170786079 bytes)
2026/03/26 10:30:37.599830 Download progress: 60% (102480576 / 170786079 bytes)
2026/03/26 10:30:37.929994 Download progress: 70% (119569520 / 170786079 bytes)
2026/03/26 10:30:38.125931 Download progress: 80% (136641520 / 170786079 bytes)
2026/03/26 10:30:38.309739 Download progress: 90% (153713520 / 170786079 bytes)
2026/03/26 10:30:38.510089 Download progress: 100% (170786079 / 170786079 bytes)
2026/03/26 10:30:38.589198 Download complete: 170786079 bytes, SHA256: cef016da0e09a41010471d8a5532f5824aa6b7f51bf80fddd5e4a441aedc2a18
2026/03/26 10:30:38.598753 Download complete
2026/03/26 10:30:38.636072 Self-elevating: c:\users\\downloads\claude setup.exe --elevated --msix-path "C:\Users\\AppData\Local\Temp\Claude-278047894.msix" --log-path "C:\Users\*\AppData\Local\Temp\ClaudeSetup.log"
2026/03/26 10:30:38.759520 Waiting for elevated process to complete...
2026/03/26 10:30:38.804729 Log file: C:\Users\*\AppData\Local\Temp\ClaudeSetup.log
2026/03/26 10:30:38.805806 === Claude Setup started ===
2026/03/26 10:30:38.806364 AllowDevelopmentWithoutDevLicense found with value: 1
2026/03/26 10:30:38.806364 Windows edition: Enterprise
2026/03/26 10:30:38.807461 Windows version: 10.0.26200
2026/03/26 10:30:38.807461 Native arch: x64
2026/03/26 10:30:38.807461 Elevation type: Full
2026/03/26 10:30:38.807461 Is elevated: true
2026/03/26 10:30:38.807461 Sideloading enabled: true
2026/03/26 10:30:38.807461 S Mode: false
2026/03/26 10:30:38.807461 Conflicting service: false
2026/03/26 10:30:38.807461 Running in elevated context
2026/03/26 10:30:38.807461 Installing MSIX from C:\Users\*\AppData\Local\Temp\Claude-278047894.msix (all-users: false)
2026/03/26 10:30:38.832452 Splash: 400x300, 8 frame(s), animated=true
2026/03/26 10:30:38.832452 System DPI: 144 (scale: 150%)
2026/03/26 10:30:38.937910 Verifying Authenticode signature on C:\Users\*\AppData\Local\Temp\Claude-278047894.msix
2026/03/26 10:30:39.299275 WinVerifyTrust: MSIX signature is valid
2026/03/26 10:30:39.411746 Signature verified: MSIX signer matches bootstrapper
2026/03/26 10:30:39.411746 Squirrel process prefix: c:\users\*\appdata\local\anthropicclaude\
2026/03/26 10:30:39.411746 Checking for running Squirrel Claude processes...
2026/03/26 10:30:39.422539 No Squirrel Claude processes found
2026/03/26 10:30:39.422539 Checking for existing Claude MSIX packages...
2026/03/26 10:30:39.438920 Removing (user): Claude_1.1.8629.0_x64__pzs8sxrjxfjjc
2026/03/26 10:30:39.451425 WARNING: Remove failed for Claude_1.1.8629.0_x64__pzs8sxrjxfjjc: RemovePackage failed with HRESULT 0x80073CFA
2026/03/26 10:30:39.451425 Installing MSIX: C:\Users\***\AppData\Local\Temp\Claude-278047894.msix
2026/03/26 10:30:39.452503 Extracted family name from MSIX manifest: Claude_pzs8sxrjxfjjc
2026/03/26 10:30:39.452503 Standard install (not split-account), using AddPackage
2026/03/26 10:30:39.452503 Installing via AddPackage (current-user)...
2026/03/26 10:30:40.705693 MSIX package installed successfully
2026/03/26 10:30:40.705693 No Squirrel installation found, skipping uninstall
2026/03/26 10:30:40.768365 MSIX installation succeeded
2026/03/26 10:30:42.771569 Launching Claude...
2026/03/26 10:30:42.772436 Launching Claude via explorer.exe shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude
2026/03/26 10:30:50.706378 === Claude Setup completed successfully ===
2026/03/26 10:30:50.750438 Elevated process exited with code 0

I had to uninstall all the things, and then the MSIX worked for me. Really concerning that this is still broken in the default downloader, and that it cant "upgrade through" the issues with a past update breaking the windows desktop version so it wouldn't open anymore.

https://downloads.claude.ai/releases/win32/x64/1.2773.0/Claude-884b3735b1ce5042a0c286824c6f9bd2d341f7c8.msix

Still experiencing this issue. Unable to install claude code on windows because it requires developer access.

Still experiencing this issue. Unable to install claude code on windows because it requires developer access.

Nearly a month later and this is still happening. I cannot install Claude Desktop (downloaded from https://claude.com/product/cowork) without developer mode.

<img width="414" height="246" alt="Image" src="https://github.com/user-attachments/assets/c55d7db5-0eaf-45f8-85e6-792782ffb777" />

Still can't install Claude desktop due to this issue. Where is a fix for this?

It's been nearly five months and one of the world's most valuable companies can't even figure out how to install their mass market app properly. Anthropic claims to be safety-first, but then asks their users to put their system into developer mode and allow sideloading. Other than the web interface, this is literally the first interaction your users have with your products. I'd only expect this kind of experience from common scammers.

Just ran into the same problem. I temporarily activated developer mode and just deactivated again after installation. Seems to be a bit nicer than the MSIX installer. Still super weird that this happens and that nobody from Anthropic replied yet.

I hit this today on Windows 11 Education (10.0.26200) on a completely unmanaged consumer machine — not domain-joined, no Intune, no AppX policy of any kind. So this is not only an enterprise problem. Installer build 03c61d06f8e01a4db2273b9514e225f21d2ba62e, resulting package 1.24012.9.0.

Since this issue has been open five months with 28 comments and no visible response from Anthropic, here is a precise root-cause writeup from my own ClaudeSetup.log. I think the actual bug is smaller and cheaper to fix than the thread suggests.

The Developer Mode requirement comes from the bootstrapper, not from Windows

Failing run:

Sideloading enabled: false
Prerequisite check failed: trusted app installs are not enabled
ERROR dialog: trusted app installs not enabled
Opening ms-settings:developers

Claude Setup.exe aborts on its own prerequisite check — while still non-elevated, before downloading anything, and before any signature check or AddPackage call is attempted. Windows never gets a say in it.

After enabling Developer Mode, the same installer build:

AllowDevelopmentWithoutDevLicense found with value: 1
Sideloading enabled: true
User can elevate — installing MSIX directly
WinVerifyTrust: MSIX signature is valid
Signature verified: MSIX signer matches bootstrapper
Installing via AddPackage (current-user)...
MSIX package installed successfully

Nothing about the package needed Developer Mode. The signature validated against the machine's trust store on the first attempt. The only thing that changed between failure and success was a registry value the installer chose to gate on.

Why that check is wrong

Per Microsoft's own documentation, sideloading of validly signed packages is enabled by default on Windows 10 2004+ and on all Windows 11 devices, and the "Allow all trusted apps to install" policy is explicitly not required:

• https://learn.microsoft.com/en-us/windows/application-management/sideload-apps-in-windows

AllowAllTrustedApps being absent or 0 is therefore the normal state of a healthy, current Windows install. Reading that as "trusted app installs are not enabled" is a false negative: the installer gates on a policy Windows does not require, then tells the user to enable a much broader developer setting to satisfy it. The finding reported earlier in this thread — that the raw .msix installs fine with Developer Mode off — is the same conclusion from the other direction. AddPackage was never the problem.

Suggested fixes, in order of preference

1. Drop the precheck. Attempt the install and surface a trust/sideloading error only if AddPackage actually returns one. A precondition check stricter than the API it guards will keep producing false negatives like this one.
2. If a precheck must stay, treat "sideloading not explicitly enabled" as allowed on Windows 10 2004+ / Windows 11, and fail only on states that genuinely block installation: S Mode, AllowAllTrustedApps=0 set via policy (HKLM\SOFTWARE\Policies\Microsoft\Windows\Appx), or "Choose where to get apps" restricted to Store-only.
3. Fix the error dialog regardless. It currently directs users to full Developer Mode. The narrow setting that satisfies the check is AllowAllTrustedApps=1, which permits validly signed packages only — no unsigned sideloading, none of the other developer surfaces. Recommending Developer Mode when trusted-app-installs is what you actually test is worse security advice than necessary, and it is a large part of why the current dialog reads like malware to people.
4. Provide a path that avoids the bootstrapper entirely — ship through the Microsoft Store, or publish the direct .msix / .appinstaller URL as a documented download instead of leaving people to extract it from installer logs.

One more reason this deserves attention

The workarounds circulating in this thread involve injecting Anthropic's signing certificate into LocalMachine\TrustedPeople or hand-editing AppX unlock keys. Both are meaningfully more dangerous than the thing they work around, and people are doing them because the official installer offered no alternative. Teaching users to lower machine-wide trust settings to install a chat client is a poor outcome for a company that leads with safety.

Original report: #25385, closed 2026-02-15 — the guidance there was to reopen if it persisted, and it does. Related Windows MSIX failures, all still open: #76357, #77380, #74170, #78873, #80502.

On routing — and a friendly ping

I'd rather not tag people at random, so to be transparent about why I'm tagging at all: I can't find any documented way to escalate this.

There is no public claude-desktop or cowork issue tracker under the anthropics org — I checked the full repo list. I also tried to leave a pointer on the original report, #25385, so that anyone arriving there from a search would find this thread; it's closed and locked, so that isn't possible. The first public report of this bug is therefore a dead end that still reads as resolved. Yet claude-ai-mcp exists specifically to collect MCP issues, so dedicated trackers clearly do get created when a surface warrants one. That leaves a Claude Desktop installer bug with nowhere correct to go except this repo, which currently has ~13,300 open issues. Under those conditions a first-install blocker sitting untouched for five months looks less like a prioritisation decision and more like nobody's queue owning it.

So: @ant-kurt, @bcherny, @ashwin-ant — apologies for the direct tag, and no offence intended if this isn't remotely your area. You're simply the people I could see actively engaging on installer and platform issues in this repo, and there's no published owner for the Windows Desktop installer to address instead. Two asks:

1. Could this be routed to whoever owns Claude Setup.exe? The diagnosis above should make it a small change.
2. Could the correct reporting route for Claude Desktop and Cowork bugs be documented somewhere — a dedicated repo, or a line in the README pointing elsewhere? Several issues in this tracker have asked exactly that and none received an answer. Fixing the routing would prevent the next five-month gap regardless of what happens to this particular bug.

I'll follow up here periodically for a status update, in the same way I would on a support ticket. Not to be a nuisance — purely because there's no other channel where this is visible.

Happy to test a fixed bootstrapper build on an unmanaged Windows 11 machine with Developer Mode off and AllowAllTrustedApps unset — precisely the configuration that fails today.