[BUG] Claude Desktop on Windows: `onQuitCleanup(mcp-shutdown)` TypeError still firing in v1.6608.2 — silent auto-restarts continue (refile of #55798)

Summary

This is a refile of #55798, which was closed on 2026-05-06 by the auto-triage bot with the message \"this doesn't appear to be about Claude Code. Please open a new issue if this is still relevant\". Per that instruction, this is the new issue.

The bug is still happening, unchanged, three Claude Desktop versions later:

| | When #55798 was filed | Now |
|---|---|---|
| Claude Desktop version | 1.5354.0 | 1.6608.2 |
| Stack trace | Cannot read properties of undefined (reading 'isDestroyed') from onQuitCleanup(mcp-shutdown) | identical (only the minified symbol name differs: CPt → e9e) |
| Trigger | Auto-restart at 5-hour usage-limit reset boundary + every manual quit | identical |
| Crashpad capture | Empty (TypeError caught + logged, never propagates) | identical |

Why the bot's classification was wrong

The auto-close said this isn't about Claude Code. It is. The MCP servers being torn down by the failing handler are loaded by CCD (the Claude Code Desktop runtime). In today's crash sequence the servers being shut down are Context7, excel, chrome-devtools, ssh-pi, obsidian, and PDF Tools — all standard CCD-managed local MCP servers, not Cowork. Cowork has its own separate cowork-vm-shutdown step that completes successfully; this bug is in the general mcp-shutdown path that runs on every Claude Desktop quit.

(For clarity: this is not a duplicate of #43534, which is Cowork-specific and only fires on extended-idle resume.)

New evidence: 35 occurrences over 11 days, 20 of them after #55798 was closed

Counting Failed to run onQuitCleanup(mcp-shutdown): TypeError entries in %APPDATA%\Claude\logs\main.log + main1.log:

| Date | Count | Notes |
|------|-------|-------|
| 2026-05-02 | 1 | |
| 2026-05-03 | 2 | |
| 2026-05-04 | 4 | |
| 2026-05-05 | 5 | |
| 2026-05-06 | 3 | #55798 closed at 22:21 ET this day |
| 2026-05-07 | 5 | first full day after close — bug unchanged |
| 2026-05-08 | 5 | |
| 2026-05-09 | 2 | |
| 2026-05-10 | 3 | |
| 2026-05-11 | 4 | |
| 2026-05-12 | 1 (so far) | |
| Total | 35 | 20 after close |

Pattern: not just the 5-hour boundary

In #55798 I focused on the 5-hour usage-limit reset trigger (:13/:14 minute mark, ~5h spacing). Looking at the broader dataset now, that's only ~70% of occurrences. The other ~30% fire on manual user-initiated quits at irregular times (e.g. 17:49, 21:30, 17:30, 03:11, 13:28). Examples:

2026-05-11 17:49:36 [error] Failed to run onQuitCleanup(mcp-shutdown): TypeError: ...
2026-05-11 21:30:34 [error] Failed to run onQuitCleanup(mcp-shutdown): TypeError: ...
2026-05-12 19:12:41 [error] Failed to run onQuitCleanup(mcp-shutdown): TypeError: ...

So the bug isn't only the silent auto-restart — it fires on every Claude Desktop shutdown, period. The user-visible symptom (silent app close + 2-second auto-relaunch with no banner or warning) only manifests on the auto-restart path, but the underlying handler is broken for all shutdowns.

Today's crash sequence (verbatim, v1.6608.2)

2026-05-12 19:12:40 [info] Running onQuitCleanup: webcontentsview-cleanup     ← destroys webContents refs
2026-05-12 19:12:40 [info] Running onQuitCleanup: prototype-cleanup
2026-05-12 19:12:40 [info] Running onQuitCleanup: remote-server-cleanup
2026-05-12 19:12:40 [info] Running onQuitCleanup: direct-mcp-host-shutdown
2026-05-12 19:12:40 [info] Running onQuitCleanup: cowork-vm-shutdown
2026-05-12 19:12:40 [info] Successfully run onQuitCleanup: preview-cleanup
2026-05-12 19:12:40 [info] Shutting down MCP Server: excel
2026-05-12 19:12:40 [info] Shutting down MCP Server: chrome-devtools
2026-05-12 19:12:40 [info] Shutting down MCP Server: ssh-pi
2026-05-12 19:12:40 [info] Shutting down MCP Server: obsidian
2026-05-12 19:12:40 [info] Shutting down MCP Server: Context7
2026-05-12 19:12:40 [info] Shutting down MCP Server: PDF Tools - View, Fill, Merge, Split, Manage Pages, Extract
2026-05-12 19:12:40 [info] Successfully run onQuitCleanup: webcontentsview-cleanup
2026-05-12 19:12:40 [info] Successfully run onQuitCleanup: cowork-vm-shutdown   ← cowork is fine
2026-05-12 19:12:41 [info] Closing utility process: id=3
2026-05-12 19:12:41 [info] Killing utility process: success=true id=3
2026-05-12 19:12:41 [error] Failed to run onQuitCleanup(mcp-shutdown): TypeError: Cannot read properties of undefined (reading 'isDestroyed')
    at e9e (C:\Program Files\WindowsApps\Claude_1.6608.2.0_x64__pzs8sxrjxfjjc\app\resources\app.asar\.vite\build\index.js:1515:5177)
    at process.processTicksAndRejections (node:internal/process/task_queues:104:5)
    at async C:\Program Files\WindowsApps\Claude_1.6608.2.0_x64__pzs8sxrjxfjjc\app\resources\app.asar\.vite\build\index.js:1515:5306
    at async C:\Program Files\WindowsApps\Claude_1.6608.2.0_x64__pzs8sxrjxfjjc\app\resources\app.asar\.vite\build\index.js:1515:4765
2026-05-12 19:12:41 [warn] [LocalMcpServerManager] Context7 disconnected
... (subsequent steps complete normally)
2026-05-12 19:12:42 [info] Successully ran all onQuitCleanup handlers, marking readyForQuit

The webcontentsview-cleanup step destroys webContents references. By the time mcp-shutdown runs, webContents is undefined — hence the TypeError on .isDestroyed. This is the same race documented in #55798.

Expected behavior

1. Defensive null-check. The mcp-shutdown handler should null-check its webContents reference before calling .isDestroyed — e.g. if (webContents && !webContents.isDestroyed) { ... }. 100% of 35 observed occurrences would be silenced by this one-line guard.
2. Don't auto-restart silently mid-session. If the app needs to refresh state at a 5-hour usage-limit boundary, do an in-place refresh or surface a banner. The current full-process tear-down loses UI state (open tab, scroll position, draft messages) with no warning.
3. Reconsider whether the 5-hour restart is necessary at all. The fact that all onQuitCleanup steps run + the app fully exits + a brand-new process starts 2 seconds later suggests this is more invasive than what's likely just a token/session refresh.

Environment

| Detail | Value |
|--------|-------|
| Claude Desktop | MSIX 1.6608.2.0 (Windows Store install) |
| Claude Code (embedded) | 2.1.128 |
| OS | Windows 11 Pro 10.0.26200 |
| Plan | Pro/Max (5-hour usage-limit window) |
| RAM | 16 GB |
| Node.js (bundled) | 24.15.0 |
| Pending update | 1.7196.0 (downloaded, not yet installed at time of report) |

Log files

• \%APPDATA%\Claude\logs\main.log\ — currently 4 most recent occurrences (May 11 13:13, 17:49, 21:30 + May 12 19:12)
• \%APPDATA%\Claude\logs\main1.log\ — rotated history with the other 31 occurrences from May 2 → May 11 04:30
• \%APPDATA%\Claude\Crashpad\reports\ and \pending\ — both still empty (TypeError is caught, never propagated)

Happy to attach scrubbed log excerpts if useful.