[macOS] ClipCascade crashes after connecting to peers on macOS 27

[breellz]

Describe the bug

On macOS 27.0 on Apple Silicon, the macOS desktop client connects to Android peers and then crashes. The menu-bar icon disappears and clipboard synchronization stops. The crash report shows SIGTRAP in -[NSStatusItem setMenu:] via pystray while a background stats thread updates the tray menu.

Steps to reproduce

1. Install the Apple Silicon macOS build.
2. Sign in and connect Android peers.
3. Wait for the peer-count/menu update.

Expected behavior

The macOS client remains running and synchronizes clipboard content with connected Android devices.

Actual behavior

The app crashes after the peers connect, leaving no usable menu-bar item and no Mac clipboard synchronization.

Environment

• macOS 27.0 (26A428)
• Apple Silicon
• ClipCascade macOS desktop release
• Android Pixel phone and tablet connected

[mjwyatt2]

Additional report of frequent ClipCascade desktop crashes on macOS 27:

• Affected: Mac mini, Apple Silicon, macOS 27.0 (26A428).
• Desktop client: official ARM 3.2.0 release; installed bundle files were compared with the official download and match.
• Comparison: ClipCascade works as expected on my MacBook Pro running macOS 26.7. Its client version/settings have not yet been independently compared.
• Symptom: desktop client exits and requires manual relaunch; the local Java server remains running.
• Review of 26 local ClipCascade crash reports from September 19–25 found 12 with this leading stack:

-[BSServiceMainRunLoopQueue assertBarrierOnQueue]
-[FBSScene _updateClientSettings:]
-[FBSScene updateClientSettingsWithBlock:]
...
-[NSSceneStatusItem _updateSupportsExpandedInterfaceSession]
-[NSStatusBarButtonCell setStatusMenu:]
-[NSStatusBarButton setStatusMenu:]

Some other reports show a short launcher stack ending in raise/SIGTRAP; these may accompany the same failure and should not be counted as separate incidents. Two reports show an invalid memory free involving CoreGraphics; one proceeds through AppKit/QuartzCore UI cleanup. These signatures do not establish a hardware defect or prove that all crashes share one cause.

During monitoring on September 25, the client logged a successful WebSocket connection at 09:59 EDT, and macOS recorded a SIGTRAP crash at 11:02:30 EDT. The Java server remained running. The client log did not record the crash. Nearby network snapshots showed the interface reachable, but they were periodic snapshots, not a continuous connectivity trace.

Does this match the menu-update threading issue described here, and is there a patch or test build that dispatches these updates onto the macOS main thread?

A local sysdiagnose and crash reports are available for targeted, redacted follow-up. The full sysdiagnose has not been uploaded.