Desktop app: loading appbrain.com in the in-app browser crashes the entire app (no crash dump, session-restore crash-loop)

## Summary

Opening https://www.appbrain.com/app/speak-english-with-loora-ai/com.loora.app in Claude Desktop's embedded browser pane kills the whole application (all windows, all sessions) within seconds to ~2 minutes of the page loading. Reproduced 2 out of 2 attempts on the same day, hours apart. Three compounding problems:

1. The crash itself — the app dies during the page's fingerprinting/anti-bot probe (WebGPU + WebGL probing; details below).
2. No crash artifacts — Crashpad's reports directory is touched at the moment of death but no .dmp is ever written. No Windows Error Reporting entry, no Event Log 1000/1002. The crash is completely invisible to post-mortem tooling.
3. Session-restore turns it into a crash-loop — each relaunch restores the poisoned tab, which kills the app again ~1–2 minutes after startup. To the user this looks like a corrupted install; the only escape they found was Settings → Apps → Repair (MSIX), which resets profile/session state and drops the tab. They repaired twice before the cause was identified.

Environment

| | |
|---|---|
| App | Claude Desktop 1.30096.1 (MSIX / Microsoft Store, package Claude_1.30096.1.0_x64__pzs8sxrjxfjjc) |
| CCD | 2.1.229 (Claude Code binary 2.1.229) |
| Runtime | node 24.18.0, win32 x64 |
| Web/desktop commits | web 26be2f5cd00fd2171d60a1b0e7a313f95f6b19af, desktop 194d93c2558cfbfcd2b8b7a90e02774c489d1875 |
| OS | Windows 11 Home build 26200 |
| GPU | Intel(R) Graphics (integrated), driver 32.0.101.8356 |
| RAM | 32 GB |

Steps to reproduce

1. In a Claude Code session in the desktop app, have the appbrain.com URL above appear as a link card in chat (or navigate the session's browser pane to it directly — both paths were hit).
2. Click it so it opens in the in-app browser pane ("Opened in Browser").
3. Wait up to ~2 minutes.

Result: the entire desktop app exits. On next launch, session-restore reloads the tab and the app dies again (observed restart→death cycles at 11:32→11:34, 11:37→11:39, 12:03→12:04 local time, 2026-08-14).

Expected: worst case, the pane's renderer tab crashes ("Aw, snap" equivalent); the app, other sessions, and the crash reporter survive. A tab that has crashed the app should not be session-restored unconditionally.

Log evidence

%APPDATA%\Claude\logs\unknown-window.log shows an identical probe wave seconds before every death (4 occurrences: 11:25:52, 11:34:33, 11:39:44, 12:04:17 local, 2026-08-14). Final occurrence, log ends mid-wave at the moment the app died:

2026-08-14 12:04:17 [error] %c%d font-size:0;color:transparent NaN
2026-08-14 12:04:17 [error] %c%d font-size:0;color:transparent NaN
2026-08-14 12:04:17 [warn] %c%d font-size:0;color:transparent NaN
2026-08-14 12:04:17 [warn] %c%d font-size:0;color:transparent NaN
2026-08-14 12:04:18 [warn] OTS parsing error: Size of decompressed WOFF 2.0 is less than compressed size
2026-08-14 12:04:20 [warn] The powerPreference option is currently ignored when calling requestAdapter() on Windows. See https://crbug.com/369219127
2026-08-14 12:04:20 [warn] The powerPreference option is currently ignored when calling requestAdapter() on Windows. See https://crbug.com/369219127
2026-08-14 12:04:20 [warn] A valid external Instance reference no longer exists.
2026-08-14 12:04:20 [warn] A valid external Instance reference no longer exists.
[log ends — app process died here]

Earlier occurrences additionally logged, right after the lines above:

WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost   (x2)

loseContext indicates the page's script called WEBGL_lose_context.loseContext() — consistent with fingerprinting/anti-bot probing (the same site 403s server-side fetchers). The %c%d … NaN console spam is a console-probe pattern from the same class of scripts.

Correlating artifacts:

• main.log marks Starting app at 11:32:07, 11:37:xx (implied by MCP log resets), 12:03:38, 12:08:49 — each pre-Repair restart died again within ~2 minutes of restoring the tab.
• Crashpad\reports LastWriteTime updates at the exact wave moment (e.g. 12:04:20) but the directory stays empty. Crashpad\settings.dat is 40 bytes. No WER entries (user or machine-wide), no Application Error/Hang events.

Ruled out: memory pressure

Full disclosure — during the first incident an unrelated runaway JVM had driven system RAM to 99% (577 MB free at 11:32, per main.log [process-memory] telemetry), which initially masked the cause. The second incident rules that out: at 12:00–12:04 the same telemetry shows ~15.5 GB free, no Java process existed, and the app still died mid-probe-wave. The page load is the trigger, not RAM.

Impact

• Any web page with aggressive fingerprinting can hard-kill the entire desktop app, taking every running Claude Code session with it (in-flight agent work is lost mid-turn).
• Because no dump/WER/EventLog artifact is produced, users have no way to attribute the crash — they blame the app or (as here) whatever they last clicked.
• Session-restore converts one bad page into a launch crash-loop that presents as a broken install and pushes users toward Repair/reinstall.

Suspected areas

1. GPU-process or Dawn/WebGPU failure during requestAdapter() probing on Intel integrated graphics propagating to main-process exit instead of being contained to the pane's renderer ("A valid external Instance reference no longer exists" is a Dawn message and is the last line ever logged).
2. Crashpad not capturing whatever exit path this is.
3. Session-restore lacking crash-loop protection for pane tabs (Chromium's own restore disables a tab after repeated crashes; the pane's restore apparently does not).

Full logs available on request: %APPDATA%\Claude\logs\main.log and unknown-window.log (note: the MSIX LocalCache mirror at %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs holds the same profile and is sometimes fresher than the %APPDATA% view).