Claude Desktop 1.49585.0 freezes: main thread deadlocks on synchronous UNUserNotificationCenter XPC call (macOS, regression of #57706)

Bug Description

Claude Desktop (Code tab, local Claude Code sessions) froze three times in one afternoon. The main thread deadlocks on a synchronous XPC call to the macOS notification service (usernoted). Force-quit was the only recovery. The third freeze ended with a Mac reboot, and the shutdown itself stalled.

This is the same deadlock as #57706 (closed as stale). It is still present in 1.49585.0.

Environment

• Claude Desktop: 1.49585.0 (Electron, node 24.20.0, arm64)
• Claude Code bundled: 2.1.260
• macOS: 26.6.2 (25G83)
• Hardware: Mac16,12 (MacBook Air, 16 GB RAM)
• ~420 local sessions restored on each launch; 3–4 sessions running at the time of each hang
• System was under memory pressure (free RAM < 100 MB, swap in use, three JetsamEvent reports the same day)

Timeline (2026-09-10, local time)

| Time | Event |
|---|---|
| 15:52–17:08 | PID 24718 froze. macOS hang report: 443 s unresponsive. Force-quit from Dock at 17:08:12. |
| 17:15–18:07 | PID 47650 (relaunched at 17:08) froze after ~7 min. macOS hang report: 171 s unresponsive. Force-quit. |
| 18:17–18:28 | PID 58290 stopped logging at 18:17:23. User rebooted the Mac at 18:28; shutdown stalled (shutdown_stall report written). |

main.log stops mid-session in all three cases with no beforeQuit / quit-cleanup entries.

Root cause (from the macOS .hang reports)

Main thread (CrBrowserMain) — all samples:

swift_addon.node + 897312
-[UNUserNotificationCenter addNotificationRequest:withCompletionHandler:]
-[UNUserNotificationServiceConnection addNotificationRequest:forBundleIdentifier:withCompletionHandler:]
_dispatch_sync_f_slow
__DISPATCH_WAIT_FOR_QUEUE__
kevent_id
  *(blocked by turnstile waiting for Claude [47650] thread 0x1765514)

Thread 0x1765514 — all samples, "last ran 373.181s ago":

NotificationService.close(id:) + 260 (swift_addon.node)
-[UNUserNotificationCenter removePendingNotificationRequestsWithIdentifiers:]
-[UNUserNotificationServiceConnection removePendingNotificationRequestsWithIdentifiers:forBundleIdentifier:completionHandler:]
_dispatch_lane_barrier_sync_invoke_and_complete
__NSXPCCONNECTION_IS_WAITING_FOR_A_SYNCHRONOUS_REPLY__
xpc_connection_send_message_with_reply_sync
mach_msg2_trap

So: NotificationService.close(id:) does a synchronous XPC round-trip to usernoted on the notification connection's serial queue. When usernoted is slow (memory pressure here), that thread blocks for minutes. The main thread then calls addNotificationRequest, which needs the same queue, and the UI deadlocks.

Both hang reports (17:00:53 and 17:15:45) show the identical pair of stacks.

Expected behavior

Notification add/remove should never block the main thread. Make NotificationService.close(id:) asynchronous (or move both calls off the main thread with a timeout), so a slow usernoted degrades notifications instead of freezing the app.

Additional notes

• After each relaunch the app restored ~420 local sessions and wrote ~2 GB to disk in 22 s (macOS disk writes diag at 19:17). Not the cause of the hang, but it adds to memory pressure on 16 GB machines.
• Full .hang reports (8.1 MB and 6.9 MB) are available on request.