[Windows][26.810.4967.0] Main process reaches 1.1-1.5 GB/s read I/O and causes system-wide lag after hours idle

Open 💬 2 comments Opened Aug 15, 2026 by DrCharlesShiSCP

💡 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.4967.0 x64

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

After Codex Desktop remains open for several hours, Windows gradually develops severe system-wide pointer and UI lag even when no Codex task is active. In the observed incident, the lag returned after approximately 4 hours 48 minutes. Fully closing Codex/ChatGPT stopped the lag immediately. Restarting the app restored a clean baseline, then the problem gradually accumulated again.

Live measurements during the lag isolated the activity to the main ChatGPT.exe desktop process:

CPU: 125-163% of one logical core in PerfMon, about 4.5% of this 32-logical-processor system
Working set: rapidly cycling between approximately 0.8 and 1.3 GB, compared with approximately 340 MB after a clean restart
Process I/O Read Bytes/sec: approximately 1.1-1.5 GB/s
Process I/O Read Operations/sec: approximately 2,889
Cumulative process reads at capture time: 495.4 GB across 1,318,408 read operations
Process writes: near zero during the live sample

Physical disk traffic remained around 0.2 MB/s, so the Process I/O counter is not reporting equivalent SSD throughput. It appears to be cached-file, pipe, device, or other internal IPC reads. I could not identify the exact endpoint without a File I/O trace.

The renderers, GPU process, bundled codex.exe backend, WMI, disk queue, DPCs, and hardware interrupts were mostly idle during the same interval. A 12-second high-frequency capture observed no hidden powershell.exe processes, and WMI showed no CPU increase.

Related reports: #38669, #38698, and #38699. This report adds process-level I/O and memory telemetry and reproduces without Modern Standby or an active task.

What steps can reproduce the bug?

Start Codex Desktop on Windows.
Leave the app open for several hours. No active Codex task is required.
Observe gradually worsening system-wide pointer and UI responsiveness.
While the lag is present, sample the Codex/ChatGPT process group using Windows Performance Monitor or equivalent counters.
Observe that the main ChatGPT.exe process consumes roughly 125-163% of one core, its working set cycles around 0.8-1.3 GB, and its Process I/O Read Bytes/sec reaches approximately 1.1-1.5 GB/s.
Compare against PhysicalDisk counters, which remain near 0.2 MB/s in this case.
Fully close Codex Desktop. System responsiveness returns immediately.
Restart Codex Desktop. Initially, the process group returns to approximately 0.13-0.27% total CPU and the lag is absent.

The issue has reproduced as a gradual buildup across app uptime. It was visible while this GitHub report was being prepared. No active agent task, Modern Standby resume, or heavy foreground workload was required.

What is the expected behavior?

When no task is active, Codex Desktop should remain near its clean idle baseline and should not accumulate a high-rate cached-file, pipe, device, or IPC read loop. Leaving the app open for hours should not cause system-wide pointer or UI lag, large working-set churn, or require restarting the app to restore responsiveness.

Additional information

Environment and diagnostic notes:

Codex App: 26.810.4967.0 x64
Subscription: Plus
Platform: Microsoft Windows NT 10.0.26200.0 x64
Bundled command runner observed: codex-command-runner 0.148.0-alpha.9
Electron/Chromium build observed in process command line: 151.0.7922.137
GPU: NVIDIA GeForce RTX 4090
CPU: 32 logical processors
Power plan: High performance
Available RAM during capture: approximately 73-80 GB
Physical disk traffic during the high Process I/O reading: approximately 0.2 MB/s
Processor queue: 0; DPC and interrupt load remained low
No WMI 5858 failures or hidden PowerShell process churn during the live lag capture
No Codex Micro or Creator Micro hardware was connected
52 present HID devices; Corsair iCUE virtual input device present
Windows PnP/HID topology logs showed no changes in the preceding 30 minutes
A WPR FileIO trace was attempted but Windows denied trace start with 0x80070005, so the exact read source could not be named

The app includes HID topology watcher and SQLite native modules, but the current evidence does not prove either is the source. The average process read size was roughly 400-500 KB per operation, which is much larger than typical HID reports.

Clean-restart comparison:

Immediately after restart: 10 ChatGPT processes, about 1.5 GB aggregate working memory, approximately 0.13-0.27% total CPU
During lag: main process working set grew from approximately 340 MB to over 1.1 GB and cycled rapidly while sustained high process-level reads continued

Closing the app was the only action needed to stop the system-wide lag immediately.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 13 days ago

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

#38640
#38583
#38698
#38669
#38699

Powered by Codex Action

oyishyi · 13 days ago

Independent reproduction on a second Windows system, now on the newer desktop package 26.810.6296.0 (internal app/runtime 26.810.50856, Chromium 151.0.7922.137).

Environment

Windows 11 x64
Intel Core i7-14700KF, 28 logical processors
NVIDIA GeForce RTX 4070 Ti 12 GB
32 GB RAM
4K 60 Hz display

User-visible behavior

After the app has been open for several hours (about five hours in this capture), mouse movement becomes discontinuous across Codex, browsers, File Explorer, and the desktop. Fully exiting Codex/ChatGPT immediately restores smooth input. Reopening the app is initially smooth and the problem returns later.

A notable symptom is that the pointer appears smooth while Task Manager is the foreground window, but becomes choppy again when a normal-integrity application is foreground. Importantly, the abnormal Codex counters below continue unchanged while Task Manager is foreground, so Task Manager appears to mask the symptom rather than stop the loop.

Independently validated process counters

I identified the Electron main ChatGPT.exe process (not the renderer, GPU process, or codex.exe backend) and sampled raw cumulative WMI counters as one-second deltas for eight seconds:

Process page faults: 226,377–323,221/sec, average 271,941/sec
Process ReadTransferCount: 897.8–1,262.0 MB/sec, average 1,106.1 MB/sec
System hard page reads: average 2.2 pages/sec; most samples were zero
Process writes were near zero

This confirms that the very high page-fault rate is overwhelmingly soft/transition faults rather than disk paging, and independently reproduces the approximately 1.1 GB/sec process-read loop reported here.

A separate eight-second capture with Task Manager confirmed as the actual foreground window showed:

Main-process CPU: 97–140% of one logical core
Process reads: 652–1,653 MB/sec
Page faults: 111,819–449,571/sec
Codex GPU-engine usage: average 4.81%, maximum 6.20%

The faulty loop therefore remains active during the apparent Task Manager foreground “recovery.”

Additional isolation

During an otherwise idle UI sample, the main process averaged about 3.4 CPU cores and peaked at about 4.7 cores.
GPU usage was usually around 5%; DPC and interrupt load were low, and no display-driver reset was recorded.
Internal app-state snapshots showed a small JS heap (about 38 MB) while main-process external/native bytes oscillated roughly 293–708 MB and RSS/working set varied by hundreds of MB.
USB reconnection, HDR, HAGS, Wacom software, Oculus/Meta services, and Virtual Desktop did not resolve it.
Disabling hardware acceleration was not part of this specific capture; the steady abnormal activity is in the Electron main process rather than the GPU process.
A WPR CPU trace could not be started from the non-elevated session (0xc5585011), so the exact call stack/read endpoint is still unknown.

No raw app-state, Sentry, ETL, or log files are attached because they may contain account identifiers, local paths, or conversation metadata.

This appears to be the same regression as this issue, persisting in 26.810.6296.0. The new evidence is the independently measured ~272k soft faults/sec and confirmation that Task Manager foreground only masks the input symptom while the main-process read/fault loop continues.