Codex Desktop renderer CPU loop when projectless/chat root is not a git repository

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

26.422.30944

What subscription do you have?

Pro

What platform is your computer?

macOS : 26.4.1

What issue are you seeing?

Summary

Codex Desktop can enter a severe renderer CPU loop when projectless/chat threads are associated with a non-git root such as ~/Documents/Codex.

The app was effectively idle, with no active reasoning thread, no active automations, and MCP servers disabled, but two Codex Helper (Renderer) processes stayed pegged around 115-130% CPU each. This caused extreme battery drain.

Observed Behavior

Activity Monitor showed:

• Two Codex Helper (Renderer) processes at ~115-130% CPU each
• Main Codex process around ~40% CPU
• codex app-server mostly idle after automations/MCP were disabled
• Energy Impact remained very high
• Killing the hot renderer PIDs did not help; Electron immediately respawned them and the new renderers became hot again

Pausing all heartbeat automations and disabling MCP servers did not resolve the renderer CPU loop.

What steps can reproduce the bug?

Evidence

Sentry breadcrumbs in:

~/Library/Application Support/Codex/sentry/scope_v3.json

were dominated by rapid repeated warnings like:

[electron-message-handler] worker_rpc_response_error
workerId=git
method=stable-metadata
errorMessage="Not a git repository"

Local Codex State

Local Codex state showed projectless/chat threads rooted under a non-git chats folder:

"thread-workspace-root-hints": {
  "...": "<CHAT_ROOT>"
}

The same state file also had a projectless-thread-ids list containing those chat/thread IDs. These appear to correspond to the new projectless “chats” feature.

At the time, <CHAT_ROOT> was not a git repository.

Log Evidence

The Codex Sentry breadcrumbs were repeatedly filled with:

[electron-message-handler] worker_rpc_response_error
workerId=git
method=stable-metadata
errorMessage="Not a git repository"

This repeated while two Codex Helper (Renderer) processes were pegged at roughly 115-130% CPU each.

Workaround

The CPU loop stopped after making the projectless/chat root a git repository.

I renamed the old chats folder:

mv "<CHAT_ROOT>" "<CHAT_ROOT>.power-debug-backup"

Then created a fresh replacement and initialized git there:

mkdir "<CHAT_ROOT>"
git -C "<CHAT_ROOT>" init

After that, the stuck renderer processes dropped to 0.0% CPU and the repeated git stable-metadata / Not a git repository breadcrumbs stopped.

What is the expected behavior?

Projectless chats should not require their root folder to be a git repository.

If Codex asks the git worker for metadata for a non-git folder, it should detect that once, cache the “not a git repository” result, and avoid retrying in a tight renderer loop.

Actual Behavior

When projectless/chat threads were rooted under a non-git folder, Codex appeared to repeatedly call git stable-metadata, receive Not a git repository, log the error, and retry continuously. This caused severe CPU and battery drain in Electron renderer processes.

Additional information

It's similar to the duplicate issue detected by Codex Action but adjacent, I believe.

Additional Reproduction: Automation Count Threshold

I found a second reproducible trigger.

With up to 4 active automations, Codex Desktop idles normally. Activity Monitor’s Energy Impact stays around ~50.

As soon as I activate a 5th automation, even with no thread visibly reasoning, Codex energy usage jumps massively:

4 active automations:  ~50 Energy Impact
5 active automations:  ~6,000-11,000 Energy Impact

This happens with both heartbeat-style automations and cron-style automations, so it does not appear specific to one schedule type.

Pausing the 5th automation causes energy usage to drop again.

Expected Behavior

Idle scheduled automations should not materially increase renderer/app-server CPU usage simply because more than 4 are enabled.

Actual Behavior

Crossing from 4 to 5 active automations appears to trigger runaway Codex Desktop energy usage, even when no visible thread is actively reasoning.

Additional local diagnostics

I reproduced the issue by activating a fifth automation while four automations were already active.

Observed immediately after the fifth automation became active:

• Codex main process jumped to roughly 150% CPU.
• codex app-server jumped to roughly 25-35% CPU.
• The primary Codex Helper (Renderer) sat around 60-70% CPU.
• Logs showed repeated idle thread resume responses, not real automation execution:
• about 10-13 composing running thread resume response entries per second
• active_turn_present=false
• active_turn_id=None
• active_turn_status=None
• In one 10-second window there were 109 idle resume responses, distributed almost evenly across the five active automation targets.

Process sampling during the spike showed the app-server with hundreds of SQLite worker threads:

• 350 distinct sqlx-sqlite-worker-* threads appeared in the app-server sample during the 5-active state.
• After pausing the fifth automation, the app-server dropped back to roughly 43 threads and low CPU.

This happened with MCP servers disabled and no active agent jobs. node_repl child processes were present but idle at 0.0% CPU.

This suggests the bug is in Codex Desktop’s automation monitoring/resume loop once active automation count reaches 5, possibly amplified by repeated SQLite/log/state work. It is not specific to chat-targeted automations; cron/workspace automations also reproduce the issue.