Main-process CPU burn ramps to ~80% of a core while idle, degrading UI responsiveness

BUG REPORT: Main-process CPU burn ramps to ~80% of a core while idle

App: OpenAI.Codex (ChatGPT desktop, MSIX) v26.803.5235.0
Severity: High - app becomes progressively unusable for navigation within ~20 min of launch

SUMMARY
-------

The Electron/Chromium main process contains a single thread that busy-loops while the
app is completely idle. The burn is not constant: it ramps monotonically from ~24% to
~80% of one CPU core over roughly 20-35 minutes after launch, then plateaus near 80%
and stays there indefinitely (measured at 80.7% after 23.5 hours of uptime).

Because the saturated thread is the main process thread that services UI and IPC, all
user interaction - especially switching between threads/conversations - becomes visibly
laggy. Streamed model responses remain fast, since they arrive over a socket that does
not contend for that thread. This produces the characteristic symptom: the app feels
heavy and slow to click through, but responses are instant once a click registers.

ENVIRONMENT
-----------

OS: Microsoft Windows 11 Enterprise, Build 26200
CPU: Intel Core i7-10610U @ 1.80GHz (4 cores / 8 threads)
RAM: 31.8 GB
GPU: Intel UHD Graphics, driver 31.0.101.2135
App version: OpenAI.Codex 26.803.5235.0
(auto-updated same day; issue also present on prior 26.730.8199.0)
Install: C:\Program Files\WindowsApps\OpenAI.Codex_26.803.5235.0_x64__2p2nqsd0c76g0

EVIDENCE 1: CPU BURN RAMPS OVER TIME, THEN PLATEAUS
---------------------------------------------------

All samples taken with the app idle - no prompt running, no typing, no streaming.
Each measurement is a CPU-time delta over a 30-90 second window.

Time since app launch Idle CPU burn (% of one core)
--------------------- -----------------------------
~1 min 24.2%
~5 min 33.5%
~20 min 70.8%
~35 min 77.5%
~53 min 76.6%
~80 min 84.3%
23.5 hours 80.7%

The curve increases monotonically and is asymptotic to roughly 78-84%, i.e. saturation
of the single thread performing the work.

EVIDENCE 2: A SINGLE THREAD ACCOUNTS FOR ESSENTIALLY ALL OF IT
--------------------------------------------------------------

Main process, 56 threads total. One thread is permanently in Running state; all others
are idle in Wait:

Id CPU_s ThreadState
----- ----- -----------
22728 142.9 Running <-- hot thread
2980 7.6 Wait
19500 5.4 Wait
2528 4.6 Wait
... ... Wait

Isolated measurement of that thread over a 40 second window:

Thread 22728 burn : 59.2% of one core
Whole process : 77.5% of one core
=> that thread is 76% of ALL process CPU

The same thread ID persists for the life of the process and its accumulated CPU time
grows continuously: 142.9 s at ~35 min uptime, rising to 567.8 s at ~53 min uptime.

EVIDENCE 3: RESOURCE HANDLES GROW ALONGSIDE CPU
------------------------------------------------

Over ~28 minutes of idle time in the main process:

Handles: 1634 -> 1759
Threads: 56 -> 57
Total app RAM: grew to 2.84 GB across 9 processes, including a +310 MB gain in a
single 45-second idle window while the window was minimized

The combination of monotonically growing CPU, growing handle count, and growing memory
in an idle process is consistent with recurring callbacks / timers / listeners being
registered but never disposed, so the volume of periodic work compounds over the
session. (Stated as consistent with the evidence, not as a confirmed root cause.)

WHAT WAS RULED OUT
------------------

Hypothesis Test performed Result
-------------------------- ------------------------------------ --------------------------------
Accumulated cache/profile Cleared 121.7 MB (caches, stale backup Burn returned to ~71% within
cruft profile, 45 MB logs) + full OS reboot 20 min of relaunch

System resource exhaustion Fresh reboot, 15.6 GB RAM free, No change to ramp behaviour
8 logical cores

Long conversation / heavy Hot thread is in the MAIN process, Renderer processes are idle
DOM not any renderer process

Render or animation loop Window minimized vs visible, 45s each Identical: 77.5% both ways

GPU / hardware acceleration gpu-process inspected separately GPU process idle; burn is in main

Filesystem watching / IO IO counter deltas on main process Only 34 reads/s, 18 writes/s
storm - negligible

Stale version Checked installed package version Already on latest (26.803.5235.0)

Process inventory at time of measurement (all from ChatGPT.exe):

PID Type
----- ----------------
19676 MAIN <-- hot thread lives here
5388 gpu-process
9896 crashpad-handler
3128 renderer
12144 renderer
10044 renderer
7728 utility
8220 utility
8072 utility

STEPS TO REPRODUCE
------------------

1. Launch the ChatGPT desktop app on Windows 11.
2. Leave it completely idle - do not send a prompt.
3. Sample the CPU time of the MAIN ChatGPT.exe process (the one that is not

--type=renderer / --type=gpu-process / --type=utility) over a 30s window,
at 1 min, 5 min, 20 min and 40 min after launch.

1. Observe CPU consumption climbing from ~25% to ~80% of one core with no user activity.
2. Optionally enumerate threads of that process and observe one thread permanently in

Running state consuming ~76% of the process's total CPU.

PowerShell used for sampling:

$p = Get-Process ChatGPT | Sort-Object WorkingSet64 -Descending | Select-Object -First 1
$a = $p.CPU
Start-Sleep 45
$b = (Get-Process -Id $p.Id).CPU
"Idle CPU burn: {0}% of one core" -f [math]::Round(($b-$a)/45*100,1)

# thread-level
(Get-Process -Id $p.Id).Threads |
Sort-Object {$_.TotalProcessorTime} -Descending |
Select-Object -First 5 Id,
@{n='CPU_s';e={[math]::Round($_.TotalProcessorTime.TotalSeconds,1)}},
ThreadState

NOTE FOR PROFILING / TRIAGE
---------------------------

A standard DevTools Performance panel recording will NOT surface this, because that
profiles a renderer target. The hot thread is in the browser/main process; all three
renderer processes are idle during the burn. A renderer-level profile is expected to
come back clean and should not be treated as evidence that the issue is absent.

To capture it, use a browser-wide trace that includes the browser process - either
chrome://tracing, or CDP Tracing.start issued against the browser-level endpoint rather
than a page target. Useful categories would include toplevel, sequence_manager, base
and scheduler, which should reveal the identity and repetition rate of the recurring
task.

Alternatively, an ETW/WPR CPU-sampling capture with stacks against the main process
would give native stack attribution for the hot thread directly.

EXPECTED VS ACTUAL
------------------

Expected: An idle desktop client should consume near-zero CPU, and should not consume
more CPU the longer it is left open.

Actual: Idle CPU consumption grows monotonically to ~80% of a core and remains there
for the lifetime of the process. UI navigation latency degrades in step with it.

IMPACT
------

• Thread/conversation switching becomes progressively laggy within ~20 minutes of launch.
• On a 4-core laptop this is ~20% of total CPU capacity burned continuously while idle,

with corresponding battery and thermal cost.

• The only effective mitigation found is to fully quit the app from the tray and relaunch,

which restores responsiveness for roughly 10-15 minutes before degrading again.
Closing the window is not sufficient; the process persists and continues to burn CPU.

• Minimizing the window does NOT reduce the burn.