[Sentry] BURROW-9V: NSInternalInconsistencyException: assertion failed: '<NSRemoteView: 0x7a4ca01e00 com.apple.SafariPlatformSupport.Helper SPCompletionListServiceViewController> notified of <NSStatusBarWindow: 0x7a496de080> but expected (null)' in -[NSRemoteView containingWindowWillOrderOnScreen:] on line...

[github-actions]

Auto-filed from Sentry by the sentry-issues workflow.

Sentry issue	BURROW-9V
Project	burrow
Level	fatal
Events	1
First seen	2026-08-03T15:23:26Z
Last seen	2026-08-03T15:23:26Z

Stack trace (most recent event)

  __exceptionPreprocess [CoreFoundation]
  objc_exception_throw [libobjc.A.dylib]
  -[NSException raise] [CoreFoundation]
  -[NSRemoteView containingWindowWillOrderOnScreen:] [ViewBridge]
  __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ [CoreFoundation]
  ___CFXRegistrationPost_block_invoke [CoreFoundation]
  _CFXRegistrationPost [CoreFoundation]
  _CFXNotificationPost [CoreFoundation]
  -[NSNotificationCenter postNotificationName:object:userInfo:] [Foundation]
  -[NSWindow _doWindowWillBeVisibleAsSheet:] [AppKit]
  -[NSWindow _reallyDoOrderWindowAboveOrBelow:] [AppKit]
  -[NSWindow _reallyDoOrderWindow:] [AppKit]
  -[NSWindow _doOrderWindow:] [AppKit]
  orderWindowFrontInAppKitOnly [AppKit]
  -[NSSceneStatusItem _wakeStatusItem] [AppKit]
  -[NSSceneStatusItem _connectVariantViewScene:] [AppKit]
  -[NSStatusBar(NSInternal) _connectVariantViewScene:] [AppKit]
  -[NSStatusItemVariantSceneDelegate scene:willConnectToSession:options:] [AppKit]
  __swift_closure_destructor.6 [AppKit]
  __swift_closure_destructor.6 [AppKit]
  __swift_closure_destructor.27 [AppKit]
  __swift_closure_destructor.27 [AppKit]
  block_destroy_helper.18 [AppKit]
  block_destroy_helper [AppKit]
  block_destroy_helper.18 [AppKit]
  keypath_get_selector_host [AppKit]
  keypath_get_selector_host [AppKit]
  __93-[FBSWorkspaceScenesClient _callOutQueue_sendDidCreateForScene:transitionContext:completion:]_block_invoke_2 [FrontBoardServices]
  __95-[FBSScene _callOutQueue_didCreateWithTransitionContext:alternativeCreationCallout:completion:]_block_invoke [FrontBoardServices]
  -[FBSScene _callOutQueue_maybeCoalesceClientSettingsUpdates:] [FrontBoardServices]

_{sentry-id: BURROW-9V — managed marker, do not edit or remove (prevents duplicate filings).}

[caezium]

Mitigation and better evidence are in #339. Normal status-item creation is deferred until one second after the initial AppKit launch turn, then gets explicit scheduled/stabilizing/stable diagnostics; the exact macOS 27 Beta 4 safeguard and learned interrupted-launch recovery remain in place. This reduces the launch-time AppKit scene race shown in this stack without claiming a proven OS root cause, and it deliberately does not add a manual compatibility override. I’m keeping this issue open until a notarized build and production telemetry confirm the result.

[caezium]

v0.11.2 is now available as a Developer ID-signed and Apple-notarized build. It defers normal status-item creation until one second after the initial AppKit launch turn, retains the exact macOS 27 Beta 4 compatibility guard and interrupted-launch recovery, and records bounded scheduled/stabilizing/stable outcomes.

I am keeping this issue open because the change mitigates the AppKit scene race shown here but does not prove the OS-level root cause. Please report any recurrence from 0.11.2 with the macOS build number and Burrow’s redacted Copy Diagnostics output.