[BUG] Desktop app Cloudflare Turnstile 403 loop on Windows 11

I am experiencing a very similar issue on macOS.

Whenever I open the Claude desktop app, a "Network Connection Failed" error briefly pops up. It then automatically redirects to the Cloudflare verification page, completes the challenge entirely on its own without requiring any manual interaction, and successfully loads the app.

Additionally, I noticed a specific pattern regarding the timing:

Long intervals: This issue always happens if I haven't used the app for a relatively long time (e.g., after a long break).

Short intervals: If I close the app and reopen it shortly after, the app launches smoothly without triggering the error or the redirect.

While it eventually lets me in, this seamless but repetitive automated loop happens every single time after a period of inactivity.

same problem, browser work, cli work, app dont lastest version, windows

Confirming this on a much newer build — and I can narrow it to a version regression.

Working: 1.22209.3
Broken: 1.24012.0 and 1.24012.1

Same machine, same network, same account, same egress IP across all three. The only variable that changed was the app version — the app auto-updated and stopped working on the next launch.

Environment

• Windows 11, MSIX package
• Claude desktop 1.24012.1 (also reproduced on 1.24012.0)
• routing configuration unchanged before and after the update

Symptoms

Every navigation to claude.ai returns 403 with a Cloudflare managed-challenge interstitial. The Turnstile iframe loads but never resolves, so accountId and orgId stay null and the app fails to start.

Chrome loads claude.ai and authenticates normally on the same machine, network and IP. api.anthropic.com is reachable throughout — the in-app updater downloaded and installed 1.24012.1 without errors during the same session that could not reach claude.ai. So the failure is specific to the embedded webview against the claude.ai zone.

Possible cause

The log shows the app rejecting three permission requests that the Turnstile widget makes, all from challenges.cloudflare.com inside the claude.ai top frame:

[info] Turnstile iframe detected. Removing error overlay.
[warn] Blocked permission check { permission: 'media', requestingOrigin: 'https://challenges.cloudflare.com/', topFrameUrl: 'https://claude.ai/' }
[warn] Blocked permission check { permission: 'background-sync', requestingOrigin: 'https://challenges.cloudflare.com/', topFrameUrl: 'https://claude.ai/' }
[warn] Blocked permission check { permission: 'notifications', requestingOrigin: 'https://challenges.cloudflare.com/', topFrameUrl: 'https://claude.ai/' }

If the challenge cannot complete without these, the permission handler may need to allow them for the challenges.cloudflare.com origin specifically.

Already ruled out

• Cleared app data and cookies — no change
• Full uninstall: Remove-AppxPackage (all users + provisioned), removed CoworkVMService, deleted all leftover data directories, rebooted, reinstalled — no change. Log confirms is_first_run: true and Filesystem virtualization active, so the install was genuinely clean.
• In-app Repair and Reset — no change

Additional observations

• Every log line is duplicated, which suggests two instances are running concurrently
• GPU process gone: { reason: 'crashed', exitCode: 101457950 } appears consistently, but the 403 loop both precedes and follows it

Seeing the exact same behavior, adding my logs as another data point.

Environment:

Claude Desktop version: 1.24012.9 (MSIX)
Windows 10.0.26200, x64, Professional edition
Fresh install (also reproduced after full uninstall + clean reinstall)

Symptoms:

Every request to https://claude.ai/ and the API returns 403 immediately on launch
Cloudflare Turnstile iframe loads and gets removed/re-triggered (Turnstile iframe detected. Removing error overlay.)
growthbook and Bootstrap API calls also fail with 403
A GPU process crash (exitCode: 101457950) shows up in the same session, but like the OP noted, the 403s start before the crash and continue after, so it looks like a separate/unrelated issue rather than the cause
Also noticed a JS error that might be relevant: [watch-record] failed to subscribe to swift events i.on is not a function — TypeError: i.on is not a function in index.chunk-D4J9UP7v.js
App eventually becomes unresponsive and prompts to "repair," which does not resolve it

What I've tried (no change):

Full uninstall via Settings > Apps, plus Remove-AppxPackage
Cleared %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc and %LOCALAPPDATA%\AnthropicClaude
Clean reinstall from claude.ai/download
Verified system clock/timezone accuracy (Asia/Tokyo, auto-sync enabled)
No VPN/proxy in use

Log excerpt:

Navigation to https://claude.ai/ failed with status code 403:
Health check returned non-200 status: { status: 403, statusText: '' }
[account] Bootstrap API returned 403
Blocked permission check { permission: 'notifications', requestingOrigin: 'https://challenges.cloudflare.com/', ... }
GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

Happy to attach full logs if useful. This looks like it's blocking new installs entirely rather than being an intermittent issue, so bumping priority seems warranted.

Confirming this on a much newer build, with some additional data points that I think change the severity assessment.

Same symptom, newer version, different geography

• App version: 1.24012.9.0 (Claude_1.24012.9.0_x64__pzs8sxrjxfjjc), MSIX package, installed from claude.ai/download
• OS: Windows 11, build 26100.4770
• Location: mainland China (the original report is from a different region, so this is not geography-specific)

The app launches, reaches the security verification step, and dies a few seconds later. main.log shows the same Cloudflare pattern:

13:04:50 [info] Turnstile iframe detected. Removing error overlay.
13:04:51 [warn] Blocked permission check { permission: 'media',
  requestingOrigin: 'https://challenges.cloudflare.com/', ... }
13:04:52 [info] Health check returned non-200 status: { status: 403, statusText: '' }
13:04:52 [info] GPU process gone: { type: 'GPU', reason: 'crashed',
  exitCode: 101457950, serviceName: 'GPU' }

The 403 health-check failures repeat throughout startup, before and around the GPU crash. Browsers on the same machine, network, and public IP authenticate to claude.ai without issue, matching the original report exactly: the failure is specific to the app's embedded web view.

This version is substantially newer than the 1.12603.1.0 in the original report, so the issue persists across a wide version range.

I can independently confirm the GPU crash is not the cause

The original report notes the 403 loop brackets the GPU crash. I tested this from the other direction and reached the same conclusion:

• Clean NVIDIA driver reinstall, 610.62 → 610.74, with "perform clean installation" checked (settings reset to defaults), followed by a reboot.
• After the reinstall the crash is byte-for-byte identical, including the same exit code, 101457950. A driver-state or driver-version fault would not reproduce the same exit code across a clean reinstall.
• Independently verified the GPU stack via webglreport.com in Chrome on the same machine: WebGL 2 fully supported, 88/88 functions implemented, renderer correctly identified as ANGLE (NVIDIA, NVIDIA GeForce RTX 5070 Ti, D3D11), Major Performance Caveat: No, and both EXT_color_buffer_float and EXT_color_buffer_half_float present.

The INVALID_ENUM: getInternalformatParameter warnings in claude.ai-web.log are normal capability probing by the Turnstile fingerprinting code, not a fault. The GPU crash appears to be a downstream symptom.

New: the failure is unrecoverable, which makes the app permanently unusable

This is the part I'd flag as more severe than currently reflected. The crash does not just fail — it corrupts the MSIX package:

1. Fresh install → Get-AppxPackage *Claude* | Select Name, Status returns Ok
2. Launch → crash at security verification
3. Immediately after the crash → status is already Modified, NeedsRemediation
4. Every subsequent launch is blocked by Windows with "This app can't open — You need to go to Advanced options for Claude and select Repair"

So a single ordinary crash puts the package into a non-launchable state that requires a full uninstall and reinstall. And because the installer auto-launches the app on completion, there is no window in which the user can intervene before the crash happens. Reinstall → auto-launch → crash → package corrupted → reinstall. It is a closed loop with no user-accessible escape.

I verified this is not recoverable through the documented path: in-app Repair and Reset both fail, matching the original report.

New: MSIX packaging blocks the obvious workaround

The natural workaround would be launching with hardware acceleration disabled. MSIX makes this impractical. I tried the package-identity-preserving route:

Invoke-CommandInDesktopPackage -PackageFamilyName "Claude_pzs8sxrjxfjjc" \
  -AppId "Claude" \
  -Command "C:\Program Files\WindowsApps\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc\Claude.exe" \
  -Args "--disable-gpu"

This fails with 0x80073CFC (package not found), because by the time the first crash has occurred the package is already in the modified state. There is no point at which the flag can be applied.

This is closely related to #45031, where the MSIX GPU flag limitation has been noted as unresolved since Feb 2026. An environment variable or a settings.json switch honored at startup would give affected users a workaround for both issues.

Suggested fixes

1. A GPU process crash should not be fatal to the main process. Handling Electron's child-process-gone to restart the GPU process or fall back to SwiftShader would at least prevent the package-corruption cascade, regardless of what the underlying Turnstile issue turns out to be.
2. A crash should not corrupt the package. Whatever writes into the package directory during abnormal termination should be moved out of C:\Program Files\WindowsApps\.
3. The installer should not auto-launch, or should offer a safe-mode launch, so users hitting this have a way to intervene.
4. Expose a hardware-acceleration toggle reachable before authentication — the in-app setting is useless when the app crashes before login.

Two secondary notes

Log path is wrong in the docs. %APPDATA%\Claude\logs\ does not exist on MSIX installs due to path redirection. The actual location is:

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\

This cost me a while to find and may be why some reports lack logs.

Orphaned package directories. C:\Program Files\WindowsApps\ on this machine holds 18 Claude package directories going back to 1.2773.0.0, none cleaned up across updates. The AppX deployment log also shows error 0x5 failures deleting files under WindowsApps\Deleted\, affecting other packages too (e.g. Clipchamp), so MSIX cleanup appears to be failing generally here. Probably unrelated to the crash, but it does mean no reinstall on this machine starts from a truly clean state.

Happy to attach full log files or run any specific diagnostic.