Desktop (Windows/MSIX): transient auth 503 → in-app Turnstile challenge → GPU crash; package left in Modified, NeedsRemediation

Summary

On Windows 11 with Claude Desktop 1.34493.1.0 (MSIX), a transient upstream authentication failure took the app from healthy to dead in eight seconds. The app held a valid cached OAuth token, the server returned 503 credential validation failed, the main window's navigation was bounced to challenge_redirect and refused with 403, a Cloudflare Turnstile bot-challenge iframe was rendered inside the app window, and the GPU process then crashed. A retry was scheduled but the app died before it fired.

Separately, and surviving a restart, the MSIX package was left in state Modified, NeedsRemediation caused by corrupted ACLs on the install directory. Settings → Repair fails with 0x80073D02 if the app is running and does not tell the user to close it.

Environment

• OS: Windows 11 Home 10.0.26200
• Claude Desktop: 1.34493.1.0
• Package: Claude_1.34493.1.0_x64__pzs8sxrjxfjjc, SignatureKind: Developer, installed via winget (Anthropic.Claude)
• Bundled Claude Code: 2.1.237
• Install path: C:\Program Files\WindowsApps\Claude_1.34493.1.0_x64__pzs8sxrjxfjjc

Part 1 — auth 503 leads to an in-app bot challenge and a GPU crash

Steps to reproduce

1. Leave the desktop app running and idle for a few hours (mine was idle ~2.8h).
2. Focus the window while Anthropic's auth service is returning 503.
3. The app attempts a skills sync and a bootstrap round on focus.

What happened

The app had been healthy for hours — 14 Electron processes, memory flat at ~1.45 GB, zero errors. Everything below happened within eight seconds of the window regaining focus.

16:05:51 [info]  [SkillsPlugin] Window focused — polling now (last poll was 10156466ms ago)
16:05:51 [info]  [oauth-v2] using cached token for orgId=<org-uuid>
16:05:51 [warn]  GET /api/bootstrap/<org-uuid>/current_user_access  -> 503 "credential validation failed"
16:05:51 [warn]  GET /api/organizations/<org-uuid>/usage            -> 503 "credential validation failed"
16:05:52 [warn]  GET /api/bootstrap/<org-uuid>/system_prompts       -> 503 "credential validation failed"
16:05:52 [warn]  GET /v1/environment_providers/private/organizations/<org-uuid>/environments?limit=1000
                 -> 503 overloaded_error "Authentication service was unavailable. You can try again."
                    request_id: req_011CeNB6huugVmWtShYrdfL8
16:05:52 [error] Failed to fetch skills list: 503 credential validation failed
16:05:52 [error] [SkillsPlugin] Sync failed: Failed to fetch skills: 503
16:05:53 [info]  Navigation to https://claude.ai/api/challenge_redirect?to=... failed with status code 403
16:05:53 [info]  Main view load failure #1 (http_error); retrying in 13s
16:05:53 [info]  Shutting down MCP Server: pdf-viewer
16:05:53 [info]  Shutting down MCP Server: <redacted second server>
16:05:54 [info]  Turnstile iframe detected. Removing error overlay.
16:05:55 [warn]  Blocked permission check { permission: 'media', requestingOrigin: 'https://challenges.cloudflare.com/' }
16:05:56 [warn]  Blocked permission check { permission: 'background-sync', requestingOrigin: 'https://challenges.cloudflare.com/' }
16:05:57 [warn]  Blocked permission check { permission: 'notifications', requestingOrigin: 'https://challenges.cloudflare.com/' }
16:05:58 [info]  GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }
16:05:59          Crashpad minidump written: 36,143,808 bytes

main.log ends at that point. The 13-second retry scheduled at 16:05:53 never ran.

Expected

A transient 503 from the auth service should surface as a retry or a "reconnecting" state. It should not escalate into a Cloudflare bot challenge rendered inside the application window, and it should not be followed by a GPU process crash.

Notes

The client was not at fault and knew it: [oauth-v2] using cached token succeeded immediately before the failures, and the server's own error body says "Authentication service was unavailable", which is a service-degraded response rather than a credential rejection. Despite that, the app's recovery path routed into an interactive bot challenge, which a desktop client cannot meaningfully complete for a background bootstrap call.

Both MCP servers were torn down as a side effect when the renderer released their ports. They were casualties of the window failing, not contributors.

Part 2 — MSIX package left in Modified, NeedsRemediation

After the crash, the package was flagged by Windows as tampered with. It was the only package on the machine with a status other than Ok.

Name                   : Claude
Version                : 1.34493.1.0
Status                 : Modified, NeedsRemediation
SignatureKind          : Developer
InstallLocation        : C:\Program Files\WindowsApps\Claude_1.34493.1.0_x64__pzs8sxrjxfjjc

The underlying cause was corrupted ACLs on the install directory, per the AppX deployment log:

Event 649: Deployment Register operation: Trying to repair ACLs for \\?\C:\Program Files\WindowsApps\Claude_1.34493.1.0_x64__pzs8sxrjxfjjc
Event 649: Deployment Register operation: ACLs repaired successfully. Register next time should succeed.

Two errors in the same repair sequence look specific to the Developer-signed sideloaded MSIX and may be worth a look:

Event 8104: Failed to set the Trust Label on package Claude_1.34493.1.0_x64__pzs8sxrjxfjjc with flags 0x0. Error: 0x80070057
Event 8107: Illegal non-AppStore or non-AppInstaller package integrity validation attempted for package Claude_1.34493.1.0_x64__pzs8sxrjxfjjc. Flags: 0x0

Sub-issue: Repair fails silently-ish when the app is running

Settings → Apps → Claude → Advanced options → Repair fails if the app is running, and the UI does not say so:

Event 404: AppX Deployment operation failed with error 0x80073D02: Unable to install because the following apps need to be closed Claude_1.34493.1.0_x64__pzs8sxrjxfjjc.
Event 638: Packages were not updated because affected apps are still running. Running apps: {Claude_pzs8sxrjxfjjc!Claude}
Event 613: Failed to reach state ResolvedDeferredRegistrations

The ACL repair inside that same failed operation does succeed, so the fix is: close the app, then re-run register. Doing that resolved it:

Add-AppxPackage -RegisterByFamilyName -MainPackage "Claude_pzs8sxrjxfjjc"
Get-AppxPackage -Name "*Claude*" | Select-Object Status   # -> Ok

Worth noting for anyone else who hits this: do not repair via winget. The winget manifest offers 1.30096.1 while the installed build is 1.34493.1.0 — the app self-updates from api.anthropic.com, well ahead of the winget package, so a forced winget install is a downgrade.

Part 3 — smaller anomalies from the same session

Failed to copy native host binary when the Chrome extension bridge starts, reading out of the read-only package directory:

17:24:30 [error] [Chrome Extension MCP] Failed to copy native host binary: Error: EBUSY: resource busy or locked, copyfile 'C:\Program Files\WindowsApps\Claude_1.34493.1.0_x64__pzs8sxrjxfjjc\...'

A refresh token that had expired produced a 403 rather than a clean re-auth prompt. The app then fell through to a still-valid cached token and carried on, so this was not user-visible, but the sequence looks unintended:

17:24:34 [error] OAuth token refresh failed: status=400, response={"error": "invalid_grant", "error_description": "Refresh token expired"}
17:24:34 [info]  [oauth-v2] refresh rejected (auth_error); tombstoning and falling through
17:24:34 [info]  [oauth-v2] performing fresh /authorize
17:24:34 [info]  oauth failed: authorize returned 403 {"type":"permission_error","message":"Session is not fresh enough to grant elevated access. Sign in again to continue."}

Resolution on my machine

The app is working again after closing it and re-running the package registration. Filing this because the crash path from a transient upstream 503 looks like a real robustness gap, and because the package ended up in a state that needed manual Windows-level intervention to recover from.