›_ Codex Issues
Codex Issues / #39134

[macOS] Recent loading loop pegs renderer at ~100% CPU; collapsing sidebar drops it to ~2%

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

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

26.810.52044 (build 6662)

What subscription do you have?

ChatGPT subscription (exact tier not verified)

What platform is your computer?

Darwin 25.5.0 arm64 arm (macOS 26.5.2, build 25F84)

What issue are you seeing?

Summary

In the macOS Codex desktop app, the Recent area can remain indefinitely in a loading state after the remote task-list request fails. While the sidebar is expanded, the primary Renderer stays near one full CPU core and retains substantially more memory. Collapsing the sidebar immediately restores normal resource usage without restarting the Renderer.

Local Codex history remains healthy during the incident.

Observed behavior

  • Recent never leaves the loading state, including after the active local turn has completed.
  • Restarting Codex and remounting/switching the view did not clear the state.
  • Local app-server thread/list requests continued to succeed quickly.
  • Desktop logs recorded repeated failures for:

/backend-api/wham/tasks/list?limit=20&task_filter=current
including timeouts/connection resets and HTTP 500/503 responses.

  • Local state databases passed PRAGMA quick_check; there was no SQLite lock or corruption error.

Same-process A/B measurement

Five samples were taken before and after collapsing the sidebar. The Renderer PID stayed the same, so this was not a process restart:

| State | Renderer CPU | Renderer RSS | Whole app CPU | Whole app RSS |
|---|---:|---:|---:|---:|
| Recent/sidebar expanded and stuck loading | 98.0% | 822.8 MiB | 120.3% | 1929.3 MiB |
| Sidebar collapsed | 1.9% | 173.2 MiB | 8.2% | 819.9 MiB |

The app-server was near idle in the high-CPU snapshot. A short process sample concentrated the hot path on the Renderer V8/JavaScript main thread while the compositor thread was mostly waiting. This points to a visible sidebar state/render loop rather than model execution or the spinner's CSS animation alone.

What steps can reproduce the bug?

  1. Launch Codex Desktop on macOS and keep the Recent sidebar expanded.
  2. Let the cloud task-list request fail or become unavailable while local thread/list still succeeds. The failure in this report occurred naturally; no network configuration was changed to induce it.
  3. Wait until the active local turn completes.
  4. Observe that Recent remains in a loading state and the primary Renderer stays near 100% CPU.
  5. Restart the app or switch away and back; the loading state may persist.
  6. Collapse the sidebar.
  7. Observe the same Renderer PID drop from about 98% CPU to about 2%, with a large RSS reduction.

The exact trigger may be the interaction between the failed cloud-list query and the visible Recent component tree, rather than either one alone.

What is the expected behavior?

A remote/cloud task-list failure must degrade gracefully without blocking healthy local task history or keeping the Renderer busy.

Most importantly, failed requests must not remain in an unbounded retry/loading loop:

  • After a bounded number of failed attempts, stop active retries and leave the loading state.
  • Render an explicit non-blocking error or stale-data state and provide a user-triggered Retry action.
  • If background recovery is necessary, use capped exponential backoff with jitter rather than continuous retries.
  • Continue rendering successful local thread/list results independently.
  • The Renderer should return to idle resource usage after the failure is handled.

Additional information

Related reports:

  • #16857: hiding the thinking/loading indicator by collapsing the sidebar lowers GPU usage.
  • #34183: /wham/tasks/list 503 responses break the merged sidebar while local thread/list remains healthy.
  • #37518: repeated conversation-list requests can leave the macOS sidebar waiting on retries.

This report adds a same-Renderer CPU/RSS A/B measurement on app version 26.810.52044. Full logs are not attached because they contain local paths and session identifiers; sanitized excerpts can be provided if needed.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 10 days ago

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

  • #38832

Powered by Codex Action

hoomoli · 9 days ago

Symptom: Codex App shows a never-ending spinner in the bottom-left "recent threads" panel, one Codex (Renderer) process pegged at 100%+ CPU, restarts don't help. Hiding the panel drops CPU immediately.

Diagnosis

  1. sample <renderer pid>: main thread is entirely in V8 microtasks/JIT, meaning a JS-level rerender loop, not a network issue.
  2. Toggle the recent-threads panel off; if CPU drops instantly, the list rendering is confirmed as the culprit.
  3. Check the database:

``bash
sqlite3 ~/.codex/state_5.sqlite "SELECT COUNT(*) FROM threads WHERE thread_source='subagent' AND archived=0;"
`
A count in the hundreds or thousands confirms it: with approvals_reviewer = auto_review`, every approval spawns a subagent thread carrying the full transcript (1MB+ titles/previews), which overloads the list.

Fix (back up first)

cp ~/.codex/state_5.sqlite /tmp/state_5.backup.sqlite
sqlite3 ~/.codex/state_5.sqlite "
DELETE FROM thread_spawn_edges WHERE parent_thread_id IN (SELECT id FROM threads WHERE thread_source='subagent') OR child_thread_id IN (SELECT id FROM threads WHERE thread_source='subagent');
DELETE FROM thread_dynamic_tools WHERE thread_id IN (SELECT id FROM threads WHERE thread_source='subagent');
DELETE FROM threads WHERE thread_source='subagent';
PRAGMA wal_checkpoint(TRUNCATE);
"

Then delete the matching rollout jsonl files (export their paths from the backup DB before deleting). Archiving (UPDATE threads SET archived=1 WHERE thread_source='subagent') is the softer option, but in this case only full deletion resolved it.

Also check: ~/.codex/process_manager/chat_processes.json accumulates dead process records; resetting it to [] helps too.

Root cause in one sentence: unbounded subagent thread accumulation plus a render loop in the list widget; clearing the data is the workaround, the widget loop is the upstream bug for the Codex team to fix.

dongseok0 · 7 days ago

Confirming the same issue on another Mac.

Environment

  • ChatGPT/Codex desktop app 26.814.41407 (build 6720)
  • macOS 26.5 (25F71), arm64

Observed

  • The bottom-left Recent spinner remains visible across full app restarts.
  • Stopping the Paseo background service and removing five stale pinned-thread references did not clear it.
  • Local thread/list continues to succeed quickly and pinnedThreads is empty.
  • macOS reports ChatGPT as Using Significant Energy
  • The primary Renderer sampled at 37.6% CPU and about 249 MiB RSS, while the app-server was at 1.4% CPU.
  • The desktop log recorded 61 occurrences of ResizeObserver loop completed with undelivered notifications over about 9m42s.
  • Local DB counts: 73 total threads, 45 subagent threads, 57 unarchived threads, and 44 unarchived subagent threads.

This appears consistent with a sidebar renderer/layout loop. It also reproduces with dozens of subagent threads, not only the hundreds or thousands mentioned in the previous comment. I can provide sanitized log excerpts if useful.

lmf · 3 days ago

Same issue, after reset the ~/.codex/.codex-global-state.json file is ok

NamelessCoder · 14 hours ago

I had the same issue and may be able to contribute with info on a consistently reproducible cause.

I had a remote system with SSH connection configured, but that remote system did not have the Codex CLI installed. This appeared to be the cause - disabling that remote connection removed the issue.

The symptom was a constantly active spinner in the side panel and like other users report here, collapsing that side panel (or switching to the settings view that doesn't show it) temporarily reduced the CPU usage. At any time when the sidebar was visible, 100% CPU usage would resume.

So in short: seems like this is a re-checking issue with no grace period or graceful failing when a remote SSH connection is inoperable. Codex will continuously attempt to connect to the remote and use the CLI and will never stop trying even after failure.