You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Codex Desktop: Codex Helper (Renderer) high CPU when popout window shortcut is enabled #19916
This is a Codex Desktop macOS app issue, not a Codex CLI issue.
What version of the Codex App are you using?
Codex Desktop 26.422.30944 (CFBundleVersion 2080)
What platform is your computer?
macOS 26.4.1 (25E253), arm64
What issue are you seeing?
Enabling the popout window shortcut appears to be strongly correlated with sustained high CPU usage in Codex Helper (Renderer) while Codex Desktop is otherwise idle.
In local testing, disabling the popout window shortcut returns CPU usage to normal. When the shortcut is enabled, Codex Helper (Renderer) can consume more than two CPU cores continuously.
The exact trigger timing seems inconsistent:
In one test, enabling the shortcut did not immediately cause abnormal CPU usage until Codex Desktop was quit and relaunched.
In another test, it looked like CPU usage became abnormal shortly after enabling the shortcut.
So this may be related to the shortcut feature initialization or renderer-side event handling, but I cannot yet say whether app restart is always required.
What steps can reproduce the bug?
Launch Codex Desktop on macOS.
Enable the popout window shortcut.
Observe Codex Helper (Renderer) CPU usage in Activity Monitor.
If CPU usage remains normal, quit and relaunch Codex Desktop.
Observe Codex Helper (Renderer) CPU usage again.
Disable the popout window shortcut.
Observe CPU usage returning to normal.
What is the expected behavior?
Enabling the popout window shortcut should not cause sustained renderer CPU usage while Codex Desktop is idle.
Additional information
This looks distinct from active model execution because the issue appears while idle and changes with the popout shortcut setting. It may be related to the global shortcut listener, popout window pre-rendering, or renderer-side event loop after loading the persisted shortcut setting.
Closing this for now. After the latest Codex Desktop update, I can no longer reproduce the high Codex Helper (Renderer) CPU issue with the popout window shortcut enabled.
If it comes back, I can reopen with fresh reproduction details.
This is still reproducing on my end - ChatGPT/Codex Desktop app version 26.825.32147 on macOS. The Codex (Renderer) process spikes to ~128% CPU specifically when I use the popout/companion window (keyboard shortcut). Sessions in the main window without using the popout don't trigger it.
Could this be reopened? It looks like the fix mentioned in the original closing comment may have regressed, or the trigger conditions are more specific (possibly related to accumulated local session history under ~/.codex/sessions, per the diagnosis in #20435 - though that issue was closed as unrelated to an MCP server deprecation without addressing the root cause described there).
Happy to share more detail (Activity Monitor screenshot, session history size) if useful.
Activity
github-actions commentedon Apr 28, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
mothieras commentedon Apr 29, 2026
Closing this for now. After the latest Codex Desktop update, I can no longer reproduce the high
Codex Helper (Renderer)CPU issue with the popout window shortcut enabled.If it comes back, I can reopen with fresh reproduction details.
mwlab-projects commentedon Sep 1, 2026
This is still reproducing on my end - ChatGPT/Codex Desktop app version 26.825.32147 on macOS. The
Codex (Renderer)process spikes to ~128% CPU specifically when I use the popout/companion window (keyboard shortcut). Sessions in the main window without using the popout don't trigger it.Could this be reopened? It looks like the fix mentioned in the original closing comment may have regressed, or the trigger conditions are more specific (possibly related to accumulated local session history under
~/.codex/sessions, per the diagnosis in #20435 - though that issue was closed as unrelated to an MCP server deprecation without addressing the root cause described there).Happy to share more detail (Activity Monitor screenshot, session history size) if useful.