[BUG] Claude Desktop auto-restarts at 5-hour usage-limit boundary on Windows — onQuitCleanup(mcp-shutdown) TypeError on undefined isDestroyed

Bug Description

Claude Desktop on Windows 11 silently restarts itself approximately every 5 hours during active use (mid-session, no idle gap). The app window disappears and reopens ~2 seconds later, breaking conversation flow with no user-facing warning.

Frequency: 27 restarts over 10 days (April 23 → May 3, 2026), per %APPDATA%\Claude\logs\main.log + main1.log. ~2.7 per day. Pattern strongly suggests the 5-hour usage-limit reset is the trigger — restarts fire ~3 minutes after a [CCD CycleHealth] You've hit your limit · resets HH:MMam/pm log entry's stated reset time.

Two issues are entangled here:

1. The auto-restart itself appears unnecessary — refreshing in-place (re-fetching auth, re-establishing sessions-bridge) without tearing down the entire process would avoid the user-visible interruption.
2. The restart sequence has a 100%-reproducible race condition: onQuitCleanup(mcp-shutdown) throws TypeError: Cannot read properties of undefined (reading 'isDestroyed') because earlier cleanup steps have already destroyed the webContents reference it tries to inspect.

Related issues

• #43534 (open) — Cowork crashes and relaunches on resume after 9hr+ idle. Different mode (idle-resume vs mid-session).
• #47147 (closed as duplicate) — CoworkVMService crash-loop. Different mode (service stopped, recovery loop).
• #40686 (closed) — Claude Code in Desktop app silently stalls mid-turn. Same era, different failure surface.

---

Stack trace (verbatim, identical across all 27 occurrences)

[error] Failed to run onQuitCleanup(mcp-shutdown): TypeError: Cannot read properties of undefined (reading 'isDestroyed')
    at CPt (C:\Program Files\WindowsApps\Claude_1.5354.0.0_x64__pzs8sxrjxfjjc\app\resources\app.asar\.vite\build\index.js:1559:5177)
    at process.processTicksAndRejections (node:internal/process/task_queues:104:5)
    at async C:\Program Files\WindowsApps\Claude_1.5354.0.0_x64__pzs8sxrjxfjjc\app\resources\app.asar\.vite\build\index.js:1559:5306
    at async C:\Program Files\WindowsApps\Claude_1.5354.0.0_x64__pzs8sxrjxfjjc\app\resources\app.asar\.vite\build\index.js:1559:4765

The error fires AFTER webcontentsview-cleanup has already run successfully and AFTER Closing utility process calls have killed MCP server processes. By the time mcp-shutdown runs, the webContents reference (likely a backref for messaging the renderer) is already undefined — hence the TypeError on .isDestroyed.

---

Reproduction Pattern — Timestamps

Sample timestamps from main.log + main1.log (consecutive 5-hour intervals visible):

2026-04-28 03:13:55
2026-04-28 08:14:04   (+5h 1m)
2026-04-28 13:14:14   (+5h)
2026-04-28 18:14:25   (+5h)
2026-04-28 23:13:35   (+5h)
2026-04-29 04:13:50   (+5h)
2026-04-29 09:14:00   (+5h)
2026-04-29 14:14:14   (+5h)
2026-04-29 19:14:24   (+5h)
2026-04-30 12:13:43
2026-04-30 17:13:58   (+5h)
2026-05-01 15:13:33
2026-05-01 20:13:31   (+5h)
2026-05-02 15:13:32
2026-05-02 20:13:43   (+5h)
2026-05-03 11:13:40

Limit-reset alignment confirmed for the two crashes today:

• 2026-05-02 18:51:47 [warn] You've hit your limit · resets 8:10pm → restart at 20:13:43 (3min after reset)
• (presumed 11:10am reset) → restart at 11:13:40 today (3min after reset)

The minute-of-hour clustering on :13 / :14 + consistent 5-hour intervals is too regular for random crashes.

---

Crash sequence (excerpt from main.log around the restart)

[info] Running onQuitCleanup: webcontentsview-cleanup     ← destroys webContents refs
[info] Running onQuitCleanup: prototype-cleanup
[info] Running onQuitCleanup: remote-server-cleanup
[info] Running onQuitCleanup: direct-mcp-host-shutdown
[info] Running onQuitCleanup: cowork-vm-shutdown
[info] Successfully run onQuitCleanup: preview-cleanup
[info] Shutting down MCP Server: Context7                 ← kills MCP processes
[info] Closing utility process: id=1
... (other MCP shutdowns: excel, chrome-devtools, ssh-pi, obsidian, PDF Tools)
[info] Successfully run onQuitCleanup: webcontentsview-cleanup
[warn] [ScheduledTasks] startVM failed: Error: VM is already running
[warn] [LocalMcpServerManager] PDF Tools - View, Fill, Merge, Split, Manage Pages, Extract disconnected
[info] Closing utility process: id=2
[info] [LocalMcpServerManager] Closing Context7
[info] Closing utility process: id=3
[info] Killing utility process: success=true id=3
[error] Failed to run onQuitCleanup(mcp-shutdown): TypeError: Cannot read properties of undefined (reading 'isDestroyed')   ← THE BUG
[info] Successfully run onQuitCleanup: cowork-vm-shutdown
... (subsequent cleanups still complete)
[info] Successfully run onQuitCleanup: local-mcp-server-cleanup
[info] Successfully ran all onQuitCleanup handlers, marking readyForQuit
[info] beforeQuit: handler fired, going down
[info] willQuit: handler fired, going down
[info] [process exits]
[info] Starting app { appVersion: '1.5354.0', isPackaged: true, platform: 'win32', arch: 'x64', nodeVersion: '24.15.0' }   ← 2-second-later auto-relaunch
[info] [CCD] Initialized with version 2.1.121

The TypeError is caught + logged but doesn't actually halt the cleanup (subsequent steps complete). Crashpad is empty (%APPDATA%\Claude\Crashpad\reports/ and /pending/ both have no entries) because nothing propagates as an uncaught exception. The "crash" is observable only through user-visible app relaunch.

---

Expected behavior

1. Don't auto-restart silently mid-session. If the app needs to refresh state at a 5-hour usage-limit boundary, surface a banner or in-place refresh — don't tear down the entire process. The current restart loses the user's UI state (open tab, scroll position, pending message draft).
2. Fix the mcp-shutdown TypeError defensively. The cleanup handler should null-check its target webContents reference before calling .isDestroyed. Currently 100% of the 27 observed restarts log this error, suggesting a missing guard like if (webContents && !webContents.isDestroyed) { ... }.
3. Investigate whether the 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 needed for what's likely a token/session refresh.

---

Environment

| Detail | Value |
|--------|-------|
| Claude Desktop | MSIX 1.5354.0.0 (Windows Store install) |
| Claude Code (embedded) | 2.1.121 |
| OS | Windows 11 Pro 10.0.26200 |
| Hyper-V | Enabled |
| Plan | (Pro/Max — has 5-hour usage-limit window) |
| RAM | 16 GB |
| Node.js (bundled) | 24.15.0 |

Log files

• %APPDATA%\Claude\logs\main.log — current session, 2 most recent crashes (May 2 20:13:43 + May 3 11:13:40)
• %APPDATA%\Claude\logs\main1.log — rotated history with 24 additional crash occurrences from April 23 → May 2

Crashpad

%APPDATA%\Claude\Crashpad\reports/ and %APPDATA%\Claude\Crashpad\pending/ are both empty — Crashpad isn't capturing this because the onQuitCleanup TypeError is caught + logged, never propagating as an uncaught exception. The user-visible "crash" is purely the post-cleanup app relaunch behavior.