macOS 26.721.81911: renderer freezes at launch in history-swipe layout effect, 100% CPU

Open 💬 3 comments Opened Jul 30, 2026 by thepriceisright
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

macOS 26.721.81911:

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

ChatGPT for macOS version 26.721.81911 (build 5973) renders normally after launch, but approximately 1–2 seconds later the UI becomes non-interactive. The window can still be scrolled, but clicks, keyboard input, navigation, and other controls stop responding. A Codex (Renderer) process uses approximately 100% of one CPU core until the application is terminated.

There is no visible error dialog, and no prompt needs to be submitted. Relevant diagnostic warnings were:

MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 destroyed listeners added to [WebContents].
warning [IpcClient] Received broadcast but no handler is configured method=client-status-changed

This later message appears to be a consequence of termination or the unresponsive renderer:

warning [IpcRouter] Socket error errorCode=EPIPE errorMessage="write EPIPE"

What steps can reproduce the bug?

  1. Install or update ChatGPT for macOS to version 26.721.81911 (build 5973).
  2. Launch /Applications/ChatGPT.app.
  3. Wait approximately 1–2 seconds after the home UI appears.
  4. Attempt to click or type anywhere.
  5. Observe that the UI is non-interactive, although scrolling may still work.
  6. Open Activity Monitor and observe Codex (Renderer) using approximately 100% CPU.

The problem also reproduces with a completely separate temporary Chromium profile:

open -na /Applications/ChatGPT.app --args \
  --user-data-dir=/private/tmp/chatgpt-codex-clean-profile

No conversation or application code is required. The failure occurs during startup before submitting a prompt, so conversation session ID, token-limit usage, and context-window usage are not applicable.

What is the expected behavior?

The app opens and remains usable.

Additional information

  • Hardware: Apple M1 Pro, 32 GB RAM.
  • OS: macOS 26.5.1 (build 25F80).
  • ChatGPT: 26.721.81911 (build 5973).
  • Embedded Chromium/Codex Framework: 150.0.7871.128.
  • Bundled Codex app-server: 0.146.0-alpha.3.1.
  • A clean --user-data-dir reproduced the issue, ruling out the normal Chromium cache, cookies, local/session storage, and service-worker state.
  • The main process, GPU process, network service, and app-server remained mostly idle while the renderer used approximately 100% CPU. Backend RPCs continued completing.
  • A five-second process sample recorded all 3,977 renderer main-thread samples inside the same V8/JIT call chain, consistent with an uninterrupted synchronous JavaScript loop.
  • V8 profiling identified the hottest application entry as a macOS-only React layout effect calling windowNavigation.setHistorySwipeNavigationState(...), behind feature gate 1645387566.
  • The repeating React layout/render stacks suggest a renderer/native navigation-state feedback loop, although the exact bridge-side trigger cannot be confirmed without source maps or native source.
  • The MaxListenersExceededWarning may be secondary but could be relevant.

chatgpt-26.721.81911-renderer-sample.sanitized.txt
chatgpt-26.721.81911-startup.sanitized.log

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 29 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #35531

Powered by Codex Action

mikegil · 28 days ago

Confirming this on the same build (26.721.81911). Same symptoms: renderer pegs at ~100% CPU on one core, clicks/keyboard stop responding, scrolling still works. Also seeing the [IpcClient] Received broadcast but no handler is configured warning repeatedly beforehand. One difference: in my case the freeze didn't happen at launch — the app ran normally for several minutes (making normal AppServerConnection/plugin/skills calls) before going unresponsive. Right before the freeze, an app/list call took 11.6s (vs. single-digit ms normally), and the last thing that completed was mcpServerStatus/list — consistent with the IPC feedback-loop theory in the original report.

thepriceisright · 28 days ago

Just upgraded to the new build Version 26.727.40816 and the issue persists with no change in behavior.

Edit: after letting the app sit, frozen, for about an hour, it seems to have recovered. Not going to close this issue however as that is clearly not desired behavior.