›_ Codex Issues
Codex Issues / #28502

Codex macOS app renderer freezes at 100% CPU after auto-starting browser/node_repl runtime

Open 💬 5 comments Opened Jun 16, 2026 by henry-insomniac
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Environment

  • Codex desktop app: 26.609.71450
  • Codex app build: 3965
  • macOS: 15.6.1
  • Architecture: Apple Silicon / arm64
  • Install source: official DMG from https://persistent.oaistatic.com/codex-app-prod/Codex.dmg

Summary

Codex desktop on macOS freezes shortly after launch. The visible symptom is the Electron renderer process pegging one CPU core at ~100%.

Reinstalling /Applications/Codex.app from the official DMG does not fix it. The issue appears to be triggered by user-local Codex state under ~/.codex, specifically the app auto-starting the browser / node_repl runtime.

Observed behavior

After launch, Codex rewrites ~/.codex/config.toml and enables browser/runtime-related entries such as:

[plugins."browser@openai-bundled"]
enabled = true

[mcp_servers.node_repl]
command = "/Applications/Codex.app/Contents/Resources/cua_node/bin/node_repl"
startup_timeout_sec = 120

It also starts processes like:

/Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled
/Applications/Codex.app/Contents/Resources/cua_node/bin/node_repl
~/.codex/computer-use/Codex Computer Use.app/.../SkyComputerUseService

Shortly after node_repl appears, the renderer spins:

Codex (Renderer)  ~100% CPU

The app UI becomes unusable / appears frozen.

Reproduction notes

This was observed on an existing local Codex profile.

  1. Launch Codex desktop app.
  2. Wait roughly 1-2 minutes.
  3. Observe node_repl being started.
  4. Observe Codex (Renderer) jump to ~100% CPU.
  5. App becomes effectively frozen.

The following did not permanently fix the issue:

  • quitting/relaunching Codex
  • reinstalling /Applications/Codex.app from the official DMG
  • clearing some app cache directories
  • disabling plugin entries in config.toml manually, because Codex rewrites parts of the config on launch

Why this does not look like a bad app install

The app bundle was replaced from the official DMG and verified as notarized:

/Applications/Codex.app: accepted
source=Notarized Developer ID

After reinstall, the same local profile still reproduced the freeze. This points to interaction between the current app version and persisted local state / plugin runtime setup under ~/.codex.

Related but likely different issue

This may be related to the broader desktop performance family, but the local trigger differs from #24510.

#24510 appears focused on high CPU from unbounded local thread metadata / sidebar history paths. In this case, the strongest correlation observed was the browser / node_repl runtime being auto-started and then the renderer immediately pegging CPU.

Expected behavior

Codex desktop should not freeze or spin the renderer at ~100% CPU when auto-starting browser / node_repl / computer-use runtime components.

If a local plugin/runtime state is incompatible, Codex should fail that runtime gracefully, avoid repeatedly starting it, and leave the main UI usable.

Actual behavior

Codex auto-starts the runtime chain and the renderer pegs ~100% CPU, making the desktop app unusable. Reinstalling the app bundle alone does not recover because the trigger appears to live in persisted user state.

Sanitization note

I have intentionally omitted full config.toml, logs, session files, and prompt history because they may contain local paths, private project data, or credentials. The snippets above are redacted to the relevant runtime entries only.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 2 months ago

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

  • #27181
  • #26989
  • #27298

Powered by Codex Action

henry-insomniac · 2 months ago

I reviewed the potential duplicates:

  • #27181 is similar in symptom, but it reproduces with a clean Chromium profile and focuses on a blank window on startup.
  • #26989 / #27298 are closer to persisted UI/global-state CPU loops.
  • This report may be related to that same Desktop performance family, but the observed trigger here is different: after launch, Codex auto-enables the bundled browser runtime and starts cua_node/bin/node_repl; shortly after node_repl appears, Codex (Renderer) jumps to ~100% CPU and the UI becomes unusable.

Reinstalling the app bundle did not help. The issue reproduces with the same ~/.codex user state after reinstall, which suggests an interaction between persisted local state and the browser/node_repl runtime startup path rather than a corrupted app install.

I do not think this is a clear duplicate unless one of the linked issues is known to share the same node_repl / bundled browser runtime root cause.

bcvictory · 1 month ago

I reproduced this on ChatGPT/Codex App 26.707.62119 (build 5211), Codex Framework 150.0.7871.115, macOS 27.0 (26A5378j), Apple Silicon.

The GUI froze after roughly 18 hours of app uptime. The primary Codex (Renderer) process was continuously using approximately 101% CPU with a 1.3 GB physical footprint. A three-second sample showed the renderer's main thread continuously executing inside v8::Script::Run.

I terminated only the affected renderer with SIGTERM. ChatGPT respawned it using the same renderer client ID and the GUI immediately recovered. The main ChatGPT process, bundled Codex app-server, active sessions, and child-session app-servers all survived.

The desktop log also contained repeated browser-use native pipe rejected socket peer reason=missing-code-signing-identity warnings. The bundled app-server had accumulated 416 direct child processes using approximately 5.43 GB RSS, which may be related, although I cannot confirm causality.

Recovery command:

kill -TERM <hot-renderer-pid>

This appears consistent with the reported renderer/browser runtime loop. Renderer-only termination also provides a recovery path that does not destroy active Codex sessions.

biabiu · 18 days ago

Confirming this on ChatGPT Desktop 26.803.41515 (Codex Framework 151.0.7922.76) on macOS 26.5.1 / Apple Silicon.

The Desktop app auto-starts the Browser/node_repl runtime shortly after launch even when the local configuration has the Browser plugin and node_repl MCP server disabled. The app also rewrites notify to the bundled SkyComputerUseClient ... turn-ended --previous-notify ... wrapper on restart.

I performed a clean-profile control test:

  1. Fully quit ChatGPT Desktop.
  2. Moved the entire ~/.codex directory aside (not deleted).
  3. Launched the app with the newly generated, empty profile.
  4. Did not restore prior sessions, SQLite state/log databases, plugin config, SSH configuration, or API settings.

Result: the runtime still auto-started shortly after launch, followed by sustained high energy use. Representative process snapshot:

  • ChatGPT main process: ~100% CPU
  • codex app-server: ~111% CPU
  • Two Codex Renderer processes: ~126% and ~112% CPU
  • Renderer RSS: ~2.2 GB and ~1.3 GB

A short sample of the hot renderer showed V8/Node serialization and GC pressure (ValueSerializer, LowMemoryNotification, PersistentRegionBase::RefillFreeList). The app-server was repeatedly in merge_loaded_apps, merge_connectors, and serialize_outgoing_message.

SSH was disconnected and syspolicyd was near 0% CPU, so this is not the Gatekeeper/FD-exhaustion variant. The clean-profile result rules out old local session history, SQLite state, or persisted plugin configuration as the primary trigger; the Desktop runtime auto-provisioning itself appears sufficient to reproduce it.

Additional confirmation: in the freshly generated profile's logs_2.sqlite, there are already 12 occurrences of browser-use native pipe rejected socket peer reason=missing-code-signing-identity. This matches the native-pipe warning reported in the renderer-recovery comment above and further points to the bundled Browser runtime startup path.

Renderer-only SIGTERM is not durable in this case: I terminated the then-hottest renderer (~206% CPU). CPU dropped briefly across the process tree, but within roughly three seconds newly spawned/recovered renderers were back at ~151% and ~142%, with app-server ~113% and the main process ~91%. So the loop is immediately re-created after renderer recovery rather than being confined to one stale renderer.

biabiu · 17 days ago

I mannually closed Codex(renderer) in activity monitor - power tab, the cpu and power usage decreased to normal level.
Then gpt reloaded GUI for 5s, and showed normal GUI
This can be a temporary solution