macOS: typing stalls with rainbow beachball around native completion notifications (26.901.51231)

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

26.901.51231 (build 8109), verified from the installed Info.plist and a live process sample on September 7, 2026. Bundle identifier: com.openai.codex. The executable/bundle is named ChatGPT on this installation.

What subscription do you have?

Not collected during this diagnostic session.

What platform is your computer?

macOS 26.5.1 (25F80), Apple M2, ARM64, 16 GB RAM.

What issue are you seeing?

When a native macOS notification banner from Codex appears in the upper-right corner, typing in the Codex composer stalls and the macOS spinning rainbow beachball appears. The user reports this happens consistently when typing coincides with an incoming Codex notification. The current version feels somewhat better than the previous version, but the problem persists. This is a user-reported trigger; the investigation below is retrospective log correlation, not a controlled reproduction.

Current logs confirm repeated browser-main-thread jank shortly after actual native notification delivery. A representative occurrence also has TextInputUI candidate-generation errors at almost exactly the jank snapshot times.

What steps can reproduce the bug?

User-reported workflow to reproduce:

1. Enable native Codex desktop notifications.
2. Have a Codex task running until it produces a completion/message notification.
3. Type in the Codex composer while that notification banner appears, for example while another task completes.
4. Observe input stalling and the macOS beachball.

Exact freeze duration and the active input source have not been measured. Whether this requires a particular IME, multiple tasks, notification sound, or focus transition is not established. No automated reproduction or notifications-on/off comparison was performed.

What is the expected behavior?

Native notifications should display without blocking the main UI thread or interrupting composer input, including while other tasks complete.

Additional information

Current-build evidence

A bounded scan of the current main-process desktop log from 2026-09-07 05:39:19 through 08:45:40 UTC found:

• 11 show notification events, all kind=turn-complete.
• 10 of those 11 events were followed within 25 seconds by at least one main_thread_jank_snapshot with processRole=browser_main.
• The whole window contains 47 jank snapshots, totaling 64 reported jank counts; jank also occurs away from notifications. This is correlation, not proof that notifications explain every stall.
• 86 ResizeObserver loop completed with undelivered notifications errors. These are generic renderer/layout errors; the word “notifications” in that error is not evidence of a native macOS notification. Native delivery was independently verified in system logs below.

Representative events (UTC; delays are time until a logged snapshot, not measured freeze durations):

Native notification request	Subsequent jank snapshot delays
07:26:47.529	+7.811 s, +19.142 s
07:40:20.581	+7.991 s, +15.699 s
08:17:41.423	+8.438 s, +16.037 s
08:22:30.649	+8.252 s, +16.210 s
08:27:08.190	+8.370 s, +15.550 s
08:41:22.796	+7.534 s, +14.632 s

Selected desktop log excerpts, with task/notification identifiers removed:

2026-09-07T08:41:22.796Z info [electron-message-handler] [desktop-notifications] show turn-complete conversationId=<redacted> rendererWebContentsId=1 rendererWindowAppearance=primary rendererWindowFocused=true rendererWindowId=1 rendererWindowVisible=true turnId=<redacted>
2026-09-07T08:41:22.796Z info [notifications-service] [desktop-notifications] forward show kind=turn-complete notificationId=<redacted>
2026-09-07T08:41:22.796Z info [desktop-notifications] show notification actionCount=0 kind=turn-complete notificationId=<redacted>
2026-09-07T08:41:30.330Z info [sampler-manager] main_thread_jank_snapshot mainThreadJankCountSinceLastSnapshot=1 processRole=browser_main snapshotReason=delta_burst windowAttention=focused
2026-09-07T08:41:37.428Z info [sampler-manager] main_thread_jank_snapshot mainThreadJankCountSinceLastSnapshot=1 processRole=browser_main snapshotReason=delta_burst windowAttention=focused

System-log timeline for the same event, local time UTC+08:00 (identifiers omitted; delivery entries summarized):

16:41:22.801 ChatGPT / com.apple.UserNotifications: Getting notification settings (async)
16:41:22.807 ChatGPT / com.apple.UserNotifications: Got notification settings [ hasResult: 1 hasCompletionHandler: 1 ]
16:41:22.812 ChatGPT / com.apple.UserNotifications: Added notification request: [ hasError: 0 hasCompletionHandler: 1 ]
16:41:22.920 usernoted: delivered the com.openai.codex notification
16:41:22.924 usernoted: presented that notification as banner
16:41:30.213 ChatGPT / com.apple.TextInputUI:CandidateGeneration: containerToPush is nil, will not push anything to candidate receiver for request token: <private>
16:41:37.365 ChatGPT / com.apple.TextInputUI:CandidateGeneration: containerToPush is nil, will not push anything to candidate receiver for request token: <private>

TextInputUI errors also occur before delivery, so they may be background noise or a contributing interaction, rather than the cause. The initial asynchronous notification-settings request returned in milliseconds; this excerpt does not show it blocking for seconds.

Diagnostic limits and related reports

A five-second main-process sample at 16:45:49 local time, outside a confirmed freeze, showed 4,132 of 4,200 main-thread observations in the ordinary run-loop Mach-message wait. It did not capture a persistent blocked notification or AppKit status-item stack. A sample taken during the actual beachball is still needed to identify the blocking call.

Related but apparently different triggers:

• #42926: native menu-bar status-item scene wait, with a captured blocking stack. That stack has not been observed here.
• #18378: freezing after Send on an older build; the reported old-build downgrade is not a verified remedy for this notification-triggered case.

No confirmed fix for this trigger was found. Disabling native notifications temporarily would be a useful controlled comparison, but has not been tested and is not claimed as a fix. No app settings, caches, conversation data, or system services were changed during this investigation.

Could maintainers investigate notification presentation/completion callbacks together with composer input/TextInputUI and browser-main-thread jank? Guidance on collecting a symbolicated sample or an app-supported trace during the short freeze would help narrow this down.

Only manually reviewed, sanitized excerpts and aggregate timings are included. No conversation contents, account identifiers, credentials, personal filesystem paths, task IDs, or raw process/system dumps are attached.

Start with the desktop-notifications, notifications-service, electron-message-handler, and sampler-manager entry points named in the logs; reproduce with native notifications enabled while typing and capture a sample during the beachball. Done means identifying the blocking call or interaction and demonstrating that notification presentation no longer stalls composer input, with relevant jank and TextInputUI evidence.