Claude Desktop Cowork freezes on session switch — synchronous XPC notification deadlock (macOS, v1.6608.2)

Bug Description

Claude Desktop (Cowork/Dispatch) freezes completely — app becomes unresponsive, macOS reports "Not Responding" — every time I switch between Cowork sessions. Force-quit is the only recovery. The app is unusable for any multi-session Dispatch workflow.

Environment

• Claude Desktop version: 1.6608.2
• macOS: 26.4.1 (Darwin 25.4.0)
• Hardware: MacBook Air M4, 16 GB RAM (Mac16,13)
• Displays: 3 (built-in Retina + 1080p + 3440x1440 ultrawide)
• MCP servers: 5 configured (supergateway-pax8, claude-m365-mcp, powerbi-mcp, claude-apple-reminders-mcp, claude-apple-messages-mcp)

Steps to Reproduce

1. Open Claude Desktop
2. Go to Dispatch / Cowork
3. Click on any Cowork session in the sidebar to switch to it
4. App freezes immediately — spinning beachball, "Not Responding" in Activity Monitor

This happens every time on session switch. It also triggers when clicking the background tasks tab.

Root Cause (from sample / spindump)

The main thread deadlocks on a synchronous XPC call to the macOS notification service. The call never returns, blocking the entire UI.

Stack trace (from sample Claude 3):

Thread DispatchQueue_299: com.apple.usernotifications.UNUserNotificationServiceConnection (serial)
  closure #1 in variable initialization expression of notificationsClose (in swift_addon.node) + 152
    NotificationService.close(id:) (in swift_addon.node) + 260
      -[UNUserNotificationCenter removePendingNotificationRequestsWithIdentifiers:] + 80
        -[UNUserNotificationServiceConnection removePendingNotificationRequestsWithIdentifiers:forBundleIdentifier:completionHandler:] + 372
          __126-[UNUserNotificationServiceConnection removePendingNotificationRequestsWithIdentifiers:forBundleIdentifier:completionHandler:]_block_invoke.71 + 288
            _NSXPCDistantObjectSimpleMessageSend3 + 76
              -[NSXPCConnection _sendSelector:withProxy:arg1:arg2:arg3:] + 136
                -[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:] + 2108
                  __NSXPCCONNECTION_IS_WAITING_FOR_A_SYNCHRONOUS_REPLY__ + 16
                    xpc_connection_send_message_with_reply_sync + 284

The problematic code is in swift_addon.node — it calls removePendingNotificationRequestsWithIdentifiers synchronously on the main thread. If the notification daemon is slow or unresponsive for any reason, the entire app deadlocks with no timeout.

What I've Tried (none of these fix it)

• Toggling notifications on/off in System Settings
• Fully disabling notifications for Claude
• Killing usernoted and NotificationCenter processes
• Restarting notification center via launchctl kickstart
• Removing an MCP server that was crash-looping (power-platform-builder-mcp)
• Multiple force-quit / relaunch cycles

Additional Context

• The swift.log shows: Authorization error: Notifications are not allowed for this application — Claude may not be properly registered with the notification center, but the toggle in System Settings shows as enabled.
• plutil -p ~/Library/Preferences/com.apple.ncprefs.plist | grep claude returns nothing — the app is not in the notification preferences database despite the UI toggle being on.
• The Dispatch session has accumulated a 113 MB transcript (transcript_size_bytes: 119059966) which may be contributing to load time, but the deadlock occurs before any transcript loading.

Suggested Fix

The NotificationService.close(id:) call in swift_addon.node should be made asynchronous or at minimum have a timeout. A synchronous XPC call on the main thread is inherently unsafe — if the notification daemon is busy, slow, or the app isn't properly registered, the entire UI freezes indefinitely.

Related

Possibly related to #47644 (Cowork hangs on launch, macOS Apple Silicon)