Skip to content

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

Open
Open
Codex macOS app renderer freezes at 100% CPU after auto-starting browser/node_repl runtime#28502
Labels
appIssues related to the Codex desktop appbrowserbugSomething isn't workingcomputer-useconfigIssues involving config.toml, config keys, config merging, or config updatesperformance

Description

@henry-insomniac
henry-insomniac
opened on Jun 16, 2026

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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    browser
    computer-use
    performance
    configIssues involving config.toml, config keys, config merging, or config updates
    on Jun 16, 2026

  2. github-actions commented on Jun 16, 2026

    @github-actions
    github-actionsbot
    on Jun 16, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. henry-insomniac commented on Jun 16, 2026

    @henry-insomniac
    henry-insomniac
    on Jun 16, 2026
    Author

    I reviewed the potential duplicates:

    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.

  4. bcvictory commented on Jul 14, 2026

    @bcvictory
    bcvictory
    on Jul 14, 2026

    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.

  5. biabiu commented on Aug 10, 2026

    @biabiu
    biabiu
    on Aug 10, 2026 – with ChatGPT Codex Connector

    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.

  6. biabiu commented on Aug 11, 2026

    @biabiu
    biabiu
    on Aug 11, 2026

    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

  7. pawsi-id commented on Sep 3, 2026

    @pawsi-id
    pawsi-id
    on Sep 3, 2026

    I am seeing the same class of intermittent full-window freezes on a current Codex/ChatGPT macOS build. When it happens, the entire desktop UI stops accepting clicks; this is not just a task waiting for approval.

    Environment:

    • ChatGPT/Codex desktop: 26.901.20858 (build 7658)
    • Bundled codex-cli: 0.153.0-alpha.5
    • Embedded Chromium: 152.0.7977.64
    • macOS 27.0 (26A5425a), Apple Silicon arm64, 48 GB RAM

    Local evidence collected while diagnosing:

    • Current app tree had 48 Codex child/helper processes using about 4.8 GB RSS.
    • 4 renderer processes used about 1.66 GB RSS in total.
    • 13 node_repl helpers and 6 mcp-remote processes were alive concurrently.
    • Crashpad recorded paired browser + renderer dump_without_crashing events at 04:44, 05:12, and 05:22 on 2026-09-04.
    • Four actual crash dumps followed at approximately 05:22-05:23.
    • Across the preceding 14 days, Crashpad recorded 45 browser and 45 renderer dump_without_crashing captures, plus 25 crash markers (spanning several app/Chromium builds).
    • System memory pressure was low: 87% free, no swap activity, and ample disk space. This does not look like host memory exhaustion.
    • A live stack sample taken while the UI was responsive showed the renderer main thread waiting normally; the failure is intermittent.

    The strong correlation with many browser/node_repl/plugin runtime helpers makes this report look closely related to #28502. Restarting recovers the UI temporarily, but the freeze recurs. Raw logs and session transcripts are omitted because they can contain local paths and project content.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbrowserbugSomething isn't workingcomputer-useconfigIssues involving config.toml, config keys, config merging, or config updatesperformance

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions