[BUG] Desktop (Windows MSIX) 1.11847.5: main webview goes unresponsive and auto-reload fails, leaving permanently black window (regression from 1.11187.4)

Environment

• App: Claude Desktop for Windows (MSIX), version 1.11847.5 (Claude_1.11847.5.0_x64__pzs8sxrjxfjjc), installed via auto-update from downloads.claude.ai
• OS: Windows 11 Pro 10.0.26200
• GPU: Intel Iris Xe Graphics, driver 32.0.101.7077 (no display-driver errors in Event Log)
• Bundled Claude Code CLI: 2.1.170

Summary

Since the app auto-updated from 1.11187.4 → 1.11847.5 (June 9, ~21:45 local), the main webview repeatedly becomes unresponsive and the app's automatic "kill and reload" recovery fails to complete, leaving the window permanently black while the backend (local sessions, permission notifications, polling) keeps running. This appears to be a regression introduced in 1.11847.5: the log covering June 6–11 shows zero occurrences before the update and 6 occurrences within ~36 h after it.

Timeline (from %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\main.log)

2026-06-09 21:46:24 [updater] Version changed since last launch: 1.11187.4 → 1.11847.5
2026-06-10 13:28:42 Main webview is unresponsive, will kill and reload   <- first ever
2026-06-10 17:59:50 Main webview is unresponsive, will kill and reload
2026-06-10 23:21:15 Main webview is unresponsive, will kill and reload
2026-06-10 23:59:15 Main webview is unresponsive, will kill and reload
2026-06-11 09:38:21 Main webview is unresponsive, will kill and reload
2026-06-11 10:17:27 Main webview is unresponsive, will kill and reload

Each "kill and reload" is immediately followed by Sentry caught: entries. Windows Error Reporting also logged two MoAppHang events for this version (June 11, 00:16), one of which coincided with Network Service process gone (reason=killed, exitCode=1) outside app quit — main-process networking is broken until relaunch.

Evidence the auto-reload fails

• After the webview goes unresponsive, the renderer process PIDs remain unchanged (still the ones created at app launch), i.e. no new renderer is spawned — the reload never completes and the window stays black.
• Killing the GPU child process (Electron respawns it cleanly, logged as GPU process gone: { reason: 'crashed' }) does not restore rendering — confirming the dead component is the webview content, not the compositor.
• OS-level recovery (Win+Ctrl+Shift+B, window resize, minimize/restore, moving between monitors) has no effect.

Repro context

Black screens tend to occur while multiple heavy local sessions run in parallel (e.g. one session with ultracode enabled plus a second concurrent session, both streaming large outputs), but also occurred overnight with idle-ish sessions. Not correlated with any GPU/driver event.

Workaround

Kill the app's process tree and relaunch (shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude); sessions resume from history. The webview's unresponsive-watchdog fires correctly — it's only the subsequent reload that never paints.

Expected

When the main webview is killed for being unresponsive, the reload should complete (or retry / surface an error UI), instead of leaving a black window indefinitely.