[BUG] macOS desktop hangs on launch after auto-update — gray screen / dock bounces forever; orphaned crashpad handlers survive quit and block early init

Summary

After the app auto-updated to 1.12603.1, Claude Desktop launches to a gray/blank window that never renders, with the Dock icon bouncing indefinitely. Quitting (Cmd+Q) and relaunching several times does not fix it — every relaunch hangs at the same early stage. The hang is before any window or rendering, so it is not the GPU-compositing blank-screen class (#26080 / #47082): --disable-gpu --disable-gpu-compositing does not help and hangs in the same place.

Environment

| | |
|---|---|
| App version | 1.12603.1 (3df4fd), built 2026-06-11 |
| Electron | 41.6.1 |
| macOS | 15.7.4 (24G517) |
| Hardware | Apple M4 Max (arm64) |

Steps to reproduce

1. Let the app auto-update to 1.12603.1.
2. Launch it.
3. Dock icon bounces; a gray window appears (or no window at all) and never paints.
4. Cmd+Q and relaunch — repeats indefinitely.

Expected vs actual

• Expected: app finishes launching and renders the UI.
• Actual: main process spins, never creates a window.

Diagnosis / evidence

• sample <pid> of the hung launch shows the main thread pinned at ~99% CPU inside very early init, before window creation:

``
ElectronInitializeICUandStartNode (in Electron Framework) + 36532
ares_dns_rr_get_ttl (in Electron Framework)
node::AsyncWrap::~AsyncWrap() (in Electron Framework)
... (also many threads parked in mach_msg2_trap)
``

• ~/Library/Logs/Claude/main.log shows no new lines after the launch attempt — the app's logger never initializes (confirms the hang is pre-logger / pre-window).
• System Events reports the process as visible: true but window count = 0.
• Found 3 orphaned chrome_crashpad_handler processes from previous app versions still running, with multi-day uptimes:

``
_version=1.9659.2 (uptime ~14d)
_version=1.11187.1 (uptime ~7d)
_version=1.11187.4 (uptime ~6d)
`
These are **not reaped on quit** and **accumulate across every update** (one per version). All point at the shared Crashpad database ~/Library/Application Support/Claude/Crashpad`.

Hypothesis

The orphaned crashpad handlers from prior versions contend for the shared Crashpad database / mach service during the new version's early crash-reporter init (which happens in ElectronInitializeICUandStartNode, before the window). The new main process spins and never reaches window creation → gray screen / endless Dock bounce.

This also explains why Cmd+Q + relaunch never fixes it: Cmd+Q gracefully quits only the main app and leaves the detached crashpad handlers (re-parented to launchd) running, so each relaunch collides with the same squatters.

Workaround that reliably fixes it

A graceful quit is not enough. Force-killing all app processes (including the orphaned crashpad handlers) and relaunching works every time:

osascript -e 'quit app "Claude"'; sleep 2
pkill -9 -f /Applications/Claude.app   # also reaps orphaned crashpad / helper processes
open -a Claude

Suggested fix

• Reap the previous version's chrome_crashpad_handler on update/quit (don't leave orphans).
• Make early crash-reporter init resilient to / not block on a contended Crashpad database (timeout or per-instance DB).