Browser/preview pane hard-crashes the entire Claude Desktop app on Windows 11 — conhost.exe AppHang, hang type `Quiesce` (correlates with KB5120998)

Summary

On Windows 11, invoking the Browser/preview pane (preview_start / navigate) reliably kills the entire Claude Desktop application. Windows logs an Application Hang (Event ID 1002) against conhost.exe with hang type Quiesce. The app then has to be repaired/reinstalled and the in-flight session is lost.

Reproduced 3/3 attempts, across two different Claude Desktop versions. It had never occurred in the preceding six months of WER history, and it started immediately after two Windows Preview updates installed — details and the correlation evidence below.

Impact

Killed two working sessions mid-task. The failure is silent from inside the session: there's no error surfaced, the app simply dies. In one case it interrupted a long-running verification task that had already spent ~15 minutes waiting on external I/O, and all of that context was lost.

Environment

| | |
|---|---|
| OS | Windows 11 Pro, build 26200 (10.0.26200) |
| Claude Desktop | MSIX/Store-packaged (Claude_…_x64__pzs8sxrjxfjjc, installed under WindowsApps) |
| Versions affected | 1.37937.3.0 and 1.40609.0.0 — both |
| Pane partition | %APPDATA%\Claude\Partitions\launch-preview-static |
| Related service | CoworkVMService (display name "Claude") |

Steps to reproduce

1. Open Claude Code inside Claude Desktop.
2. Have the assistant call the Browser pane — navigate or preview_start with any https:// URL. (Mine was an ordinary public page; the URL appears irrelevant.)
3. The call reports success (navOk: true, a serverId is returned), then the whole app hangs and closes.
4. Windows Application log records Event 1002, conhost.exe, hang type Quiesce.

Secondary tell: a following javascript_tool call fails with "No preview is open" before a subsequent preview_start succeeds — the pane is dying and being re-created underneath.

Evidence

All three Application Hang events — note the final field:

14:20:33  conhost.exe  10.0.26100.8972  …  C:\Windows\System32\conhost.exe  …  Quiesce
16:04:26  conhost.exe  10.0.26100.9278  …  C:\Windows\System32\conhost.exe  …  Quiesce
16:54:40  conhost.exe  10.0.26100.9278  …  C:\Windows\System32\conhost.exe  …  Quiesce

CoworkVMService ("Claude") then terminated unexpectedly 3× over the following minutes.

This is a new failure. WER's ReportArchive retains ~6 months on this machine and contains exactly three AppHang_conhost.exe reports — all three from the same day. The archive was actively recording throughout that window (it holds AppHang reports for several unrelated third-party applications across those months), so the absence is real and not a retention artifact. Win32_ReliabilityRecords agrees: three records, same day.

Note for anyone reproducing this: the Windows Application event log is circular and on a default 20 MB cap may only retain ~27 hours, so it cannot establish "never happened before". WER and Reliability Monitor can.

Correlation — what actually changed

13:13:05  KB5122385  (2026-08 .NET Framework PREVIEW Update)    install STARTED
13:16:26  KB5120998  (2026-08 PREVIEW Update, build 26200.9278) install STARTED
14:20:33  >>> FIRST-EVER conhost.exe AppHang / Quiesce <<<      (mid-install)
14:26:11  both updates report Installation Successful

The first-ever occurrence lands inside the update window, and conhost.exe moves 10.0.26100.8972 → 10.0.26100.9278 — the build KB5120998 delivers.

Ruled out:

• Claude Desktop version. Crash #1 ran on 1.37937.3.0, which had been in use since the previous day with no incident; crash #3 ran on 1.40609.0.0. Package deployment history shows 1.40609.0.0 first appeared after crashes #1 and #2 — it was the repair, not the cause.
• Install corruption. A clean reinstall of the latest package did not fix it.
• conhost version. The hang occurred on both .8972 and .9278.
• AV / AMSI. A concurrent eamsi.dll "DLL injection protection blocked" flood turned out to be emitted by an unrelated third-party peripheral utility, not by Claude.

Prime suspect: KB5120998 (possibly with KB5122385). Both are Preview (optional, non-security) updates.

Hypothesis

Quiesce is the PLM (Process Lifecycle Management) suspend handshake, which applies to packaged (MSIX) apps. The Browser pane isn't a passive viewer — it spawns a local preview server and an Electron BrowserView, and that spawn goes through a console-hosted subprocess, creating a conhost.exe. That child appears to inherit the package identity and get pulled into the package's quiesce set; a console host isn't PLM-aware, never completes the suspend handshake, so Windows declares a hang, kills it, and tears down the package — taking the app with it.

The most useful lead, and the thing I couldn't explain: ordinary Bash/PowerShell tool calls spawn console processes continuously throughout a session without ever triggering this. So it isn't console-spawning as such — it's specific to the pane's spawn path (plausibly via CoworkVMService rather than the CLI process tree). That difference is probably where the fix lives.

Workaround

Treat browser automation as unavailable: avoid the Browser pane entirely. Where a browser is genuinely required, drive it manually outside Claude and paste results back into the session.

Untested candidate fix

Uninstalling KB5120998 should confirm or refute causation. It's a Preview/optional, non-security update, so removing it shouldn't reduce security posture (that month's actual Security Update is a separate KB). I have not performed this yet.