Linux desktop: concurrent full-session searches saturate CPU

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

26.810.52044

What subscription do you have?

Not included because it is not relevant to this local CPU issue.

What platform is your computer?

Ubuntu 26.04 LTS, x86_64, 32 logical CPUs.

The ChatGPT desktop executable is /usr/lib/chatgpt/ChatGPT. Its bundled Codex app server is /usr/lib/chatgpt/resources/codex. The locally installed CLI reports codex-cli 0.149.0.

What issue are you seeing?

A Codex Desktop task triggered multiple concurrent ripgrep searches over the entire local session-history directory, saturating the machine CPU.

At 23:17:57 +08:00, three rg processes had parent PID equal to the bundled Codex app-server process. They each searched ~/.codex/sessions using a command equivalent to:

rg -l --fixed-strings --ignore-case --no-ignore --glob '*.jsonl' -- '<long task query>' ~/.codex/sessions

Observed CPU consumption per process was approximately 945%, 815%, and 765%, respectively. A one-second process sample immediately afterward showed several such rg processes between roughly 700% and 1200% CPU. With other desktop processes, this saturated the 32 logical CPUs.

The history directory contains 1,951 JSONL files and is about 20 GiB. The largest file is about 613 MB. The visible session index is only 112 KiB / 721 lines.

Desktop logs in the same interval showed repeated thread/search calls together with fuzzyFileSearch/sessionUpdate. The rg processes exited after the burst; there was no persistent unrelated CPU-heavy process that accounted for it.

This is distinct from a general rendering/GPU issue. A separate cc-switch process scanned approximately 2,011 files but used only about 16% CPU during the relevant sample. localsearch-3 was also present around 25% CPU, but it did not account for the spike.

What steps can reproduce the bug?

1. Use ChatGPT Desktop in Codex mode on Linux with a large shared ~/.codex/sessions history.
2. Have a task attempt to inspect/search prior chat or session history broadly.
3. Observe the bundled Codex app server launching multiple rg commands with --no-ignore against all *.jsonl under ~/.codex/sessions.
4. On a multi-core system, observe CPU saturation and degraded desktop responsiveness.

The exact query text was intentionally omitted because it came from local conversation content. The issue does not depend on its wording; the problematic behavior is repeated concurrent full-history raw-file scanning.

What is the expected behavior?

A history lookup should remain responsive and should not consume most or all available CPU.

In particular, the desktop app/task runtime should:

• constrain searches to the relevant task/session where possible;
• use the local session index/state rather than raw-scanning every JSONL file when feasible;
• cap search concurrency and respect cancellation;
• avoid --no-ignore whole-history searches for routine history lookup;
• provide a bounded/streamed fallback for unusually large history stores.

Additional information

The direct process ancestry was:

ChatGPT Desktop -> bundled codex app-server -> rg (multiple concurrent processes)

This was an observed incident, not a synthetic benchmark. I can provide sanitized timestamps or further environment details if needed, but I cannot share raw local session JSONL files because they contain private task history.

Start with the bundled Codex app-server history-search path and reproduce the issue using a large ~/.codex/sessions directory. Inspect the desktop logs for repeated thread/search and fuzzyFileSearch/sessionUpdate calls, then trace the app-server-launched rg processes. Done means routine lookups avoid unbounded concurrent whole-history scans, cap concurrency, respect cancellation, and remain responsive.