Repository navigation
[macOS] Desktop input lag after repeated ResizeObserver errors #44730
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.903.71938
What subscription do you have?
ChatGPT paid subscription (tier omitted from public issue)
What platform is your computer?
Darwin 25.6.0 arm64 arm macOS 26.6.2 (25G83), Apple M5 Pro
What issue are you seeing?
On ChatGPT/Codex Desktop for macOS, text input becomes delayed and the UI feels like it is stuttering. The user observed the lag while typing Korean and English; during the episode, lag was also reported in other apps.
In the affected session, the desktop log repeatedly emitted:
[electron-message-handler] [desktop-notifications][global-error] ResizeObserver loop completed with undelivered notifications.
A window reload (⌘⌃R / Reload Window) did not resolve the symptom. A separate Logi Options+ resource spike was observed and restarting its service reduced that process from about 893 MB and 1,454 threads to about 144 MB and 136 threads. The app-side renderer/layout condition remains a suspected contributor.
Measured during the episode:
- Codex App: 26.903.71938; bundled Chromium/Codex Framework: 152.0.7977.83
- OS: macOS 26.6.2 (25G83), Apple Silicon arm64
- Displays: built-in 3024×1964 Retina XDR plus external 1920×1080 at 120 Hz
- Codex renderer: about 956 MB RSS and about 14% CPU at one sample
- WindowServer: about 893 MB RSS and about 37% CPU at the same sample
- The ResizeObserver line occurred 453 times in the captured app log
These measurements were captured locally. No raw logs, prompts, account identifiers, or local paths are included.
What steps can reproduce the bug?
- Launch ChatGPT/Codex Desktop on the macOS setup above.
- Leave a Codex conversation active while it is streaming or handling tool activity.
- Type and delete Korean or English text in the composer.
- Observe delayed key appearance and intermittent UI stutter; in this session, the user also observed lag in other apps.
- Press ⌘⌃R to reload the window. The input lag remains and the ResizeObserver messages continue to accumulate in the app log.
What is the expected behavior?
Text entry and deletion should remain responsive while a conversation is streaming. ResizeObserver warnings should be bounded and should not trigger repeated layout work or contribute to global UI/compositor lag.
Additional information
Related reports: #42495 (macOS ResizeObserver log flooding) and #33996 (ResizeObserver loops correlated with visible UI freezes on Windows). This report is macOS-specific and focuses on user-visible input latency and compositor load.
Please advise whether there is a supported workaround or a build that fixes this behavior. Account and billing details are intentionally omitted from this public issue.
Activity
github-actions commentedon Sep 11, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
area46006 commentedon Sep 15, 2026
Confirmed the same warning-plus-lag pattern on Linux.
Environment:
26.908.70816amd640.154.0-alpha.6.2During ordinary interaction, the main renderer logged 87 occurrences of:
within roughly ten minutes while the UI was severely slow. There was no
render-process-goneevent. Local account/auth/model/config calls were generally 4–90 ms, thread resume was 605 ms, and turn start was 131 ms. This supports a frontend/UI performance problem rather than an account or authentication failure, while still treating the ResizeObserver correlation as evidence rather than proven causality.The Linux-specific report #45610 is being closed as a duplicate of this issue so the cross-platform confirmations remain together.
No raw logs, usernames, local paths, account identifiers, or session content are included.
CN1231 commentedon Sep 16, 2026
Adding a Windows observation related to the repeated ResizeObserver reports here. This is correlation, not proof that the warning is the root cause of UI latency.
26.908.9136.0.0.154.0-alpha.6.2.ResizeObserver loop completed with undelivered notificationsbetween 2026-09-16 05:09:49 UTC and 06:29:03 UTC. Sampled lines identify the focused, visible primary renderer.fs/readDirectorytook 7 ms at 05:53 UTC and 2 ms at 06:17 UTC;config/readtook 39 ms at 06:05 UTC. These are individual samples, not a latency distribution.Is there a supported diagnostic flag, workaround, or fixed build that can identify the renderer layout involved without modifying the signed app bundle or clearing user state?
No raw logs, prompts, account identifiers, local paths, or workspace data are included. A responsive backend is not being presented as proof that the UI problem is resolved.