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

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:

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.

No source file or test is named. Reproduce the failed /backend-api/wham/tasks/list request with the Recent sidebar expanded, then trace the renderer state and request handling for that view while confirming local thread/list remains healthy. Done means failed cloud requests stop retrying indefinitely, Recent shows a non-blocking error or stale state with user-triggered retry, and renderer usage returns to normal.