[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

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?

1. Start Codex Desktop on Windows.
2. Leave the app open for several hours. No active Codex task is required.
3. Observe gradually worsening system-wide pointer and UI responsiveness.
4. While the lag is present, sample the Codex/ChatGPT process group using Windows Performance Monitor or equivalent counters.
5. 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.
6. Compare against PhysicalDisk counters, which remain near 0.2 MB/s in this case.
7. Fully close Codex Desktop. System responsiveness returns immediately.
8. 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.

No source file or test is named. Start by reproducing the issue on Windows, then trace the main ChatGPT.exe process during prolonged idle to identify the source of the sustained reads and working-set cycling. Done means idle uptime no longer accumulates high process I/O, memory churn, or system-wide lag.