Issue Station
Sign In
Tools hereToolbox

codex - 💡(How to fix) Fix Codex Desktop macOS: renderer CPU spike with repeated stable-metadata "Not a git repository" errors [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#18837•Fetched 2026-04-22 07:51:46
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Author
UP1982UP1982
Participants
github-actions[bot]github-actions[bot]UP1982UP1982
Timeline (top)
labeled ×2closed ×1commented ×1marked_as_duplicate ×1

Error Message

Codex Desktop should not keep multiple renderer processes pinned above 100% CPU when only one window is open and the app is idle or lightly used. Git metadata checks should fail gracefully without creating a high-volume renderer error loop or sustained CPU usage. In one fresh restart log, I counted 22,894 occurrences of that error.

RAW_BUFFERClick to expand / collapse

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

Version 26.417.41555 (1858)

What subscription do you have?

Pro 5x

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Codex Desktop on macOS launches 3 Codex Helper (Renderer) processes for a single visible window, and 2 of those renderers stay pinned around 118% to 131% CPU even when the app is idle or lightly used. At the same time, the renderer logs repeatedly emit worker_rpc_response_error errorMessage="Not a git repository" method=stable-metadata workerId=git. This continues after restarting the app and after resetting Codex app state.

bug-report-artifacts.tar.gz

What steps can reproduce the bug?

Uploaded thread: 019dac38-5275-7540-a26e-26250e368f5a Open Codex Desktop on macOS. Open or restore a normal Codex window/thread. Let the app sit idle or use it lightly. Open Activity Monitor. Observe that there are 3 Codex Helper (Renderer) processes and that 2 of them stay above 100% CPU. Check the Codex logs under ~/Library/Logs/com.openai.codex/ and observe repeated stable-metadata / Not a git repository errors.

What is the expected behavior?

Codex Desktop should not keep multiple renderer processes pinned above 100% CPU when only one window is open and the app is idle or lightly used. Git metadata checks should fail gracefully without creating a high-volume renderer error loop or sustained CPU usage.

Additional information

I already tried multiple local fixes and the issue still reproduces:

  • quit and relaunch Codex
  • reset ~/Library/Application Support/Codex
  • reset broader OpenAI desktop state under ~/Library/Application Support/com.openai.chat
  • recreate missing workspace paths
  • initialize Codex scratch folders as git repositories
  • add initial commits, local origin config, and local origin/main / origin/HEAD refs to those scratch repos

None of those steps fixed the problem.

Environment:

  • Codex Desktop 26.417.41555
  • Build 1858
  • Electron 41.2.0
  • macOS 26.5 (25F5058e)
  • Apple Silicon / arm64

Most recent observed process state:

  • 1 visible Codex window
  • 3 renderer processes
  • 2 renderers around 118% to 131% CPU

Relevant log pattern:

  • worker_rpc_response_error errorMessage="Not a git repository" method=stable-metadata workerId=git

In one fresh restart log, I counted 22,894 occurrences of that error.

Related issues that may be relevant:

  • #18545 (macOS renderer / WindowServer CPU)
  • #18515 (stable-metadata git log loop, VS Code extension)

extent analysis

TL;DR

The issue can be mitigated by investigating and resolving the "Not a git repository" error causing the high CPU usage in the Codex Helper (Renderer) processes.

Guidance

  • Investigate the worker_rpc_response_error logs to understand why the stable-metadata method is failing with a "Not a git repository" error, as this seems to be the root cause of the high CPU usage.
  • Verify that the git repositories used by Codex are properly initialized and configured, as the user has already attempted to recreate missing workspace paths and initialize Codex scratch folders as git repositories.
  • Check if the issue is related to the Electron version (41.2.0) or the macOS version (26.5), and consider updating or downgrading if necessary.
  • Review the related issues (#18545 and #18515) to see if they provide any insights or solutions to the problem.

Example

No code snippet is provided as the issue seems to be related to the configuration and interaction between Codex and git repositories.

Notes

The issue may be specific to the user's environment or configuration, and further investigation is needed to determine the root cause. The high CPU usage and repeated error logs suggest a potential issue with the git repository setup or the stable-metadata method.

Recommendation

Apply workaround: Investigate and resolve the "Not a git repository" error, as this seems to be the primary cause of the issue. This may involve checking the git repository configuration, updating dependencies, or modifying the Codex setup.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#prompt template#agent execution#callback error#memory management#API rate limit

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix Codex Desktop macOS: renderer CPU spike with repeated stable-metadata "Not a git repository" errors [1 comments, 2 participants]