macOS app beachballs in status-item scene creation after Control Center reports mismatched pid version

What version of the Codex App are you using (From “About Codex” dialog)?

26.901.41123 (7942), verified from the live process sample and installed Info.plist. The app is /Applications/ChatGPT.app, bundle identifier com.openai.codex; embedded Chromium framework version 152.0.7977.64.

What subscription do you have?

ChatGPT personal account; exact subscription tier not recorded.

What platform is your computer?

Apple Silicon Mac, 64 GB RAM, macOS 26.5.1 (25F80). Live app sample reports ARM64.

What issue are you seeing?

The desktop app intermittently becomes unresponsive with a macOS beachball. During this occurrence, two separate five-second samples showed the main UI thread blocked in the same synchronous dispatch wait while AppKit creates a menu-bar status-item auxiliary scene. Control Center repeatedly rejected connections for that exact app process with RBSRequestErrorDomain Code=3: process has mismatched pid version.

Observed timeline, September 5, 2026, EDT (UTC-04:00):

• App launched September 4 at 20:33:22.
• By 00:17:05–00:17:10, Control Center was repeatedly reporting the process-identity error. AppKit logged failed scene/auxiliary-scene activations and XPC reply errors.
• Last desktop app log entry was at 00:17:04.545; system logs continued until the status-item wait.
• At 00:23:46 and again around 00:24, all main-thread observations in each five-second sample (4,173 and 4,176 observations) remained in the stack below.

Selected main-thread stack, omitting unrelated framework frames:

__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__
__34-[NSSceneStatusItem _requestScene]_block_invoke.17
-[NSSceneStatusItem _requestScene]
-[FBSScene(FBSWorkspaceService) activateWithCompletion:]
-[FBSWorkspaceScenesClient activateSceneFuture:completion:]
... scene creation callbacks ...
-[NSStatusItemScene initWithSession:connectionOptions:]
-[NSStatusBar(NSInternal) _connectScene:]
-[NSSceneStatusItem _connectScene:]
-[NSSceneStatusItem _setupScene:]
-[NSSceneStatusItem _addAuxiliaryView:named:]
-[NSSceneStatusItem _requestAuxiliaryViewScene:]
-[FBSWorkspaceService createScene:]
-[FBSWorkspaceScenesClient createSceneFutureWithDefinition:]
-[BSServiceDispatchQueue performAsyncAndWait:]
_dispatch_async_and_wait_f
_dispatch_async_and_wait_f_slow
__DISPATCH_WAIT_FOR_QUEUE__
_dispatch_event_loop_wait_for_ownership
_dispatch_kq_poll
kevent_id

Representative system errors (process/scene identifiers omitted):

ControlCenter [com.apple.FrontBoard:Process]:
Unable to resolve vpid <app-pid>(<pid-version>):
RBSRequestErrorDomain; code: 3; "process has mismatched pid version"

ChatGPT [com.apple.AppKit:StatusBar]:
scene activation failed: Error Domain=BSServiceConnectionErrorDomain Code=3
"XPC error received on message reply handler"

ChatGPT [com.apple.AppKit:StatusBar]:
auxiliary scene activation failed: Error Domain=BSServiceConnectionErrorDomain Code=3
"XPC error received on message reply handler"

ChatGPT [com.apple.AppKit:StatusBar]:
Unhandled disconnected scene <private>
Unhandled disconnected auxiliary scene <private>

ChatGPT [com.apple.BaseBoard:Common]:
[BSBlockSentinel:FBSWorkspaceScenesClient] failed!

The main process CPU usage was near zero. memory_pressure -Q reported 38% system-wide memory free. The sampled renderer main thread spent approximately 97% of observations waiting on Mach messages, with some continuing work. These observations favor a persistent main-thread status-item wait over a CPU-bound renderer loop or global memory exhaustion.

What steps can reproduce the bug?

No deterministic reproducer yet. The user reports occasional recurrence during normal desktop use. This occurrence was captured live before restarting or modifying the app.

Two independently launched instances of the same installed app were running with separate personal/work configuration homes. The personal instance beachballed. Control Center also emitted the same process-identity error for the other instance, which remained usable. Whether multiple instances contribute is unknown.

No CLI upgrade or app-bundle replacement was established as the trigger in this occurrence. The installed bundle was present before the sampled process launched.

Diagnostic collection:

sample <main-app-pid> 5 1 -file main.txt
sample <renderer-pid> 5 1 -file renderer.txt
# Repeat the main-process sample to confirm persistence.
log show --last 20m --style compact --predicate 'process == "ControlCenter" AND eventMessage CONTAINS "<main-app-pid>"'

What is the expected behavior?

A failed or stale menu-bar scene connection should recover or disable the status item without permanently blocking the main UI thread. The app window and existing work should remain usable.

Additional information

Related: #23695 has a similar AppKit status-item synchronous wait, but describes a suspected Homebrew CLI-upgrade trigger. This report adds a current-build occurrence and correlated Control Center process-identity/XPC failures; the entry path here is auxiliary scene creation rather than status-item drawing. These may share an underlying defect.

The desktop log also contained ResizeObserver loop completed with undelivered notifications warnings before the freeze. Their causal role is unproven; the captured main-thread blockage is in native AppKit status-item creation.

The installed app exposes a General setting to show the app in the macOS menu bar. Disabling it is a possible workaround to test, not a verified fix. No restart, cache deletion, settings change, or system-service restart was performed during diagnosis.

Full process samples and targeted system logs were preserved locally. Only sanitized excerpts are included here; no conversation transcripts, account identifiers, credentials, personal filesystem paths, or full system dumps are attached.

Start by reviewing the captured main-process samples and the targeted Control Center logs, focusing on the NSSceneStatusItem auxiliary-scene creation path and the synchronous wait. Compare the behavior with related issue #23695 and test whether disabling the macOS menu-bar setting changes recurrence. Done means the app remains responsive when scene activation fails or the stale connection is reported.