[BUG] Desktop (Windows MSIX): watchdog kills unresponsive webview but never reloads it, and single-instance handling then blocks the user's own relaunch — Task Manager is the only exit

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

Two separate defects compound into an unrecoverable app:

1. The reload never fires. When the watchdog detects an unresponsive main webview it logs Main webview is unresponsive, will kill and reload, kills the renderer, and then never reloads. The main process stays healthy; the window is left with no content renderer, permanently white.
2. The obvious recovery is actively blocked. Closing the window with Alt+F4 and relaunching does not work: the window closes but the main process survives, so the single-instance handler suppresses the new instance and restores focus to the same renderer-less window. A user who doesn't know to force-kill the process has a permanently broken app with no visible way out.

The second defect is arguably the more important one — even if the webview hang is hard to fix, the app should not trap the user.

52 occurrences between 2026-07-16 and 2026-09-07, with zero self-recoveries. Every one of the 52 was recovered by a full application cold start after the user force-quit the process. Two occurred this morning, on the current build.

This is not a version regression

The 52 hangs span 14+ distinct builds, from 1.22209.0 through 1.46388.4, with no version boundary anywhere in the series:

1.22209.0  1.24012.0  1.24012.1  1.24012.9  1.24012.11  1.26832.0  1.28929.0
1.30096.1  1.30096.5  1.32885.1  1.34493.0  1.34493.1  1.37937.0  1.37937.1
1.37937.3  1.40609.0  1.40609.1  1.44121.1  1.44121.2  1.44121.4
1.46388.1  1.46388.2  1.46388.3  1.46388.4

Rate is essentially flat across the period — 1.55 hangs/day over Aug 21–31, 1.57/day over Sep 1–7 — so this is a long-standing defect, not a recent regression, and not something that resolves on its own with updates.

Note for triage: #67459 reported this same fault as a regression from 1.11187.4 and was closed as invalid. The version framing there appears to have been coincidental; the data below shows the fault predates and outlives any single build.

Environment

| Field | Value |
|---|---|
| Platform | Windows 11 x64 |
| App version (current) | 1.46388.4 |
| Electron / Node | 42.10.0 / 24.18.1 |
| Install source | MSIX / Windows Store |
| System RAM | 16 GB, typically 1.7–3 GB free at fault time |
| Local MCP servers | Filesystem (stdio), claude-in-chrome, mcp-registry |

No in-app recovery path

Confirmed by direct testing:

| Attempt | Result | Why |
|---|---|---|
| Ctrl+R | No effect | The accelerator dispatches to the focused webContents, which has been destroyed. The window isn't hung — it's empty. |
| Alt+F4, then relaunch | Same white window returns | Window closes, main process does not exit. Single-instance suppresses the new instance and refocuses the dead window. |
| Alt+F4 again | No effect | — |
| Task Manager → End task | Works | Only genuine process termination lets a subsequent launch reach Loaded https://claude.ai. |

The suppression is visible in the log:

2026-08-30 09:28:18 [info] Main webview is unresponsive, will kill and reload
...
2026-08-30 10:16:00 [info] second-instance: suppressing duplicate argv     <- user relaunches, suppressed
2026-08-30 10:16:10 [info] Loaded https://claude.ai                        <- user force-quits, real start

Trigger correlation: artifact iframe renders

The consistent signature in claude.ai-web.log immediately before a hang:

[warn]  Failed to execute 'postMessage' on 'DOMWindow': The target origin provided
        ('https://www.claudeusercontent.com') does not match the recipient window's origin
[error] Unrecognized Content-Security-Policy directive 'webrtc'.
[warn]  [ARTIFACTS] Received message does not conform to basic message shape, ignoring

Where the preceding tool call is visible it is present_files — an HTML file delivered into the conversation and rendered in the preview pane.

The base rate reproduces across two independent windows. I computed it separately on two non-overlapping log sets, collapsing artifact events into bursts (>5 min gap = new burst) and counting a hang as correlated if a burst ended within 240 s before it:

| Window | Artifact bursts | Hangs preceded by a burst | Rate |
|---|---|---|---|
| 2026-07-27 → 2026-08-20 | 227 | 16 | 7.0% |
| 2026-08-21 → 2026-09-07 | 225 | 20 | 8.9% |
| Combined | 452 | 36 | 8.0% |

Roughly 1 in 12 artifact renders ends in an unrecoverable window. Larger self-contained HTML documents appear more likely to trigger it. (Seven further hangs on 2026-07-16 and 07-25 predate renderer-log coverage and are excluded from both rows rather than counted as negatives.)

Hang counts by day

Jul 16  4     Aug 05  2     Aug 21  2     Aug 30  5     Sep 05  3
Jul 25  3     Aug 09  1     Aug 22  1     Aug 31  2     Sep 06  2
Jul 28  1     Aug 13  1     Aug 24  4     Sep 01  1     Sep 07  2  (by 08:07)
Jul 29  1     Aug 14  3     Aug 27  2     Sep 03  3
              Aug 16  3     Aug 28  1
              Aug 17  1
              Aug 18  1
              Aug 19  2
              Aug 20  1

Ruled out

| Hypothesis | Evidence against |
|---|---|
| Version regression | 14+ builds affected, 1.22209.0 → 1.46388.4, flat rate throughout. See above. |
| Memory pressure / renderer OOM | Renderer RSS at artifact loads that hung: median 506 MB, mean 511 MB (n=17). At loads that did not hang: median 506 MB, mean 490 MB (n=219). Indistinguishable. System free RAM 1.7–3 GB of 16 GB at fault time. |
| GPU process / hardware acceleration | GPU process gone: { reason: 'killed', exitCode: 1 } appears only in the same second as Network Service process gone ... outside app quit — i.e. only on force-quit. A consequence of the quit, not a precursor. (This distinguishes the fault from #44558, which was attributed to compositor surface loss.) |
| Uptime / memory creep | Start-to-hang ranges 0.1 h to 49.1 h with no pattern; two hangs within 6 minutes of a fresh start. |
| The eipc_message listener leak | See below — the leak and the hangs are decoupled. |
| Hardware / drivers | Never memory-starved; no disk or driver errors in any log. |

Secondary: EventEmitter listener leak (probably unrelated)

claude.ai-web.log contains large numbers of:

MaxListenersExceededWarning: Possible EventEmitter memory leak detected.
11 $eipc_message$_<window-uuid>_$_... listeners added.

I initially suspected this was the mechanism by which the renderer thread blocks. The data does not support that. Daily counts:

Jul 28 - Aug 26   2-13/day
Aug 27            105
Aug 28             58
Aug 29            100
Aug 30             73
Aug 31            119
Sep 01            101
Sep 02              9
Sep 03 - Sep 07   5-16/day

The leak spiked ~10× for six days and then returned to baseline, while the hang rate stayed flat across that entire transition (1.55/day before, 1.57/day after). Whatever causes the listener accumulation, it is not gating the webview lockup. Reporting it as a separate defect worth fixing on its own merits, not as a lead on this one.

Also present, offered without a causal claim: [LOCAL_SESSION] Subagent parent not found for user message - possible out of order processing, [ARTIFACTS] Received message does not conform to basic message shape, ignoring, [LOCAL_STORAGE] IndexedDB state read did not settle within the hydration timeout.

Suggested areas to investigate

1. The reload path after killAndReload. The kill executes and is logged; no subsequent loadURL or webview re-creation ever is, in 52 of 52 occurrences. The reload appears to fail silently or never be invoked — possibly because it is scheduled on a handler the kill itself tears down.
2. A watchdog fallback. Even if the reload fails, detect that the window has no content renderer after N seconds and retry, or surface an error state, rather than leaving a white window.
3. Single-instance handling during the fault. second-instance currently restores focus unconditionally. If the target window has no renderer, it should recreate it — or the app should exit and let the new instance take over — instead of re-presenting a dead window to a user explicitly trying to restart. This alone would remove the "no way out" property of the bug, independently of any fix to the hang.
4. The artifact iframe postMessage handshake. The target-origin mismatch against www.claudeusercontent.com and the non-conforming-message warning appear immediately before the large majority of lockups, at a rate that has now replicated across two independent windows.

Related prior reports

Both closed without a fix; neither established the artifact-render correlation or the single-instance suppression:

• #67459 — same log line, same MSIX platform, reload never completes, renderer PIDs unchanged. Closed as invalid. Framed as a regression from 1.11187.4; the version data above suggests that framing was incidental.
• #44558 — intermittent permanent blank window on Windows 11, force-quit the only recovery. Attributed there to GPU/compositor surface loss, which the process telemetry above rules out for this case.

Workaround for affected users

Ctrl+Shift+Esc → End task on Claude → relaunch. Or right-click the tray icon → Quit (the main process is healthy during the fault, so the tray generally still responds). Avoiding the in-app preview pane for HTML artifacts — opening the file in an external browser instead — avoids the trigger.

Logs available

main.log, main1.log (173k lines combined, covering 2026-07-16 → 2026-09-07 and all 52 fault sequences) and claude.ai-web.log (renderer console), plus window.log, mcp.log, mcp-server-Filesystem.log, ssh.log, chrome-native-host.log, cowork_vm_node.log. Sentry event IDs for 18 of the occurrences available on request. Happy to provide any of it.

What Should Happen?

The webview should be reloaded after being killed, as the app's own log message says it will (Main webview is unresponsive, will kill and reload), restoring the UI without user intervention.

Failing that, the app should at minimum not block the user's own recovery: relaunching after closing the window should produce a working window rather than being suppressed by single-instance handling and refocused onto the dead one.

Error Messages/Logs

## Fault sequence (identical in all 52 occurrences)

From `main.log`, this morning's second hang:


2026-09-07 07:50:39 [info] Main webview is unresponsive, will kill and reload
2026-09-07 07:50:39 [info] [EventLogging] Flushing 3 events
2026-09-07 07:50:40 [warn] [event-loop-stall] main process blocked for 582ms
                           (task webrequest:headers-received=0ms, total 5, cumulative 3492ms, rss 211MB)
2026-09-07 07:50:40 [info] Shutting down MCP Server: Filesystem
2026-09-07 07:50:40 [info] Closing utiltiy proccess: id=4
2026-09-07 07:50:40 [info] Killing utiltiy proccess: id=4
2026-09-07 07:50:40 [info] [process-memory] trigger=stall tree_rss_sum=2599MB electron(10)=2262MB
                           top=[electron_renderer:40560:812MB electron_renderer:8604:500MB
                                child:48680:301MB electron_main:45564:211MB electron_gpu:47708:182MB]
                           sys_free=1692MB/16068MB


Sentry raises `Main webview became unresponsive` at the same instant. **No `loadURL` or webview re-creation is ever logged afterward.**

Process-memory telemetry shows the renderer gone and never replaced. Nine minutes after an earlier hang the tree is still flat:


06:15:23  tree_rss_sum=1614MB  electron(10)  top=[renderer:16764:492MB renderer:36304:487MB main:17932:188MB gpu:29124:179MB]
06:15:34  tree_rss_sum= 536MB  electron(7)   top=[main:17932:177MB gpu:29124:125MB renderer:25728:52MB utility:27404:47MB]
06:16:33  tree_rss_sum= 529MB  electron(7)   ... (unchanged)
06:26:22  tree_rss_sum= 524MB  electron(7)   ... (unchanged, 11 minutes later)


Process count 10 → 7. The only surviving renderer is a ~52 MB background webview. The main process continues normal work throughout (updater checks, plugin sync, OAuth refresh, bridge reconnects) — it is healthy; only the window content is gone.

### Recovery is always a cold start, never a reload

For each of the 52 hangs I checked whether an `MSIX detected` line (which only appears on a full application start) occurs between the hang and the next `Loaded https://claude.ai`:


cold starts: 52    self-reloads: 0


Time-to-recovery ranges from 20 seconds to 54 hours and tracks only how long it took the user to notice and force-quit — not any property of the fault.

Steps to Reproduce

Steps to reproduce

Not deterministic (~8% per render), but reliably reproducible over a session:

1. Open a long-running conversation on Claude Desktop for Windows (MSIX).
2. Have Claude deliver HTML artifacts into the conversation via present_files and view them in the preview pane. Larger self-contained documents seem more likely to trigger it.
3. Repeat. Within ~12 renders the webview locks up, is killed, and does not come back.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

N/A - this is Claude Desktop for Windows, not the CLI. Claude Desktop 1.46388.4 (MSIX / Windows Store), Electron 42.10.0, Node 24.18.1

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

GitHub flagged #76725 as a possible duplicate. It is related but distinct: that report covers hangs 50–90s after launch where the watchdog's reload does succeed and the app stabilises after 2–3 cycles. This report covers mid-session hangs where the reload never fires at all and the window stays dead until the process is killed. The two may share an upstream cause in the main-thread stall, but the failure described here (reload never invoked + relaunch suppressed) does not appear in #76725.

Note on the form fields above: this is a Claude Desktop bug, not a Claude Code CLI bug, so "Claude Code Version", "Platform" and "Terminal/Shell" have no meaningful value. The desktop build is 1.46388.4 (MSIX / Windows Store), Electron 42.10.0, Node 24.18.1.