Codex Desktop 26.611.8604.0 causes intermittent system input lag on Windows despite clean logs/plugins disabled

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

• #28735
• #28440
• #27394

Powered by Codex Action

In-app Codex feedback/session ID for this report:

019ed4e1-678b-7eb0-b47f-fdc9d387f24f

This was submitted after filing the issue so the team can connect the GitHub report with the shared Codex session context.

Reviewed the potential duplicates suggested by github-actions:

• #28735 is related but was for 26.611.61753, focuses on chat switching/composer typing latency, and is already closed.
• #27394 is related but was for 26.608.12217 and is also closed.
• #28440 is the closest match: Windows renderer/app CPU hogging after session start. This issue may share the same underlying root cause.

I am leaving this issue open for now because it adds version-specific and cleaner reproduction evidence for 26.611.8604.0:

• observed update from 26.611.8273.0 to 26.611.8604.0 during the monitoring window
• reproduced after rotating the previous huge logs_2.sqlite* files, with the new DB staying small around 16 MB
• CPU bursts remained in Codex.exe main/GPU/renderer processes rather than being explained by log growth
• ambient suggestions disabled + plugin bundles disabled + active node_repl removed did not resolve it
• runtime priority/affinity containment did not fully protect system input responsiveness
• in-app feedback/session ID is linked above

Happy for maintainers to merge/close as duplicate if #28440 is the canonical tracker, but I wanted to keep this evidence attached because it narrows the failure mode to the current Windows Desktop build and a clean-log reproduction.

Adding sanitized laptop specs, since this is relevant to ruling out underpowered hardware:

• OS: Windows 11 Home 10.0.26200 x64
• CPU: Intel Core i9-14900HX
• CPU topology: 24 physical cores / 32 logical processors
• RAM: 32 GB total, 2 x 16 GB DDR5-5600
• GPU: NVIDIA GeForce RTX 4070 Laptop GPU, driver 32.0.15.7283
• Integrated GPU also present: Intel UHD Graphics, driver 31.0.101.5445
• Primary storage: ~1 TB NVMe/SSD-class drive (E18-1TB-PHISON-SSD-BICS5)
• Active Windows power scheme during investigation: Balanced
• AC processor max state was checked/restored to 100% earlier in troubleshooting

No serial number, hostname, username, or private paths included here. The machine is substantially above what should be needed for normal Codex Desktop UI responsiveness, which is why the system-wide input lag while Codex is open looks like an app-side regression rather than a hardware limitation.

Adding an important user-observed onset date:

• The user first noticed Codex-related mouse/typing/system lag on June 12, 2026.
• Before June 12, Codex Desktop did not noticeably degrade this laptop's responsiveness.
• Local evidence aligns with that timeline: the archived logs_2.sqlite data showed a large retained-log spike on 2026-06-12 before later spikes on 2026-06-17 and 2026-06-18.
• The later update from 26.611.8273.0 to 26.611.8604.0 appears to be a second/current phase: after clean-log rotation, lag still reproduced with small logs and Codex Desktop main/GPU/renderer CPU bursts.

So the timeline is likely:

1. June 12, 2026: first user-visible performance regression begins; local log data also shows a major spike that day.
2. June 17-18, 2026: additional spikes / renewed troubleshooting.
3. June 18, 2026: update to 26.611.8604.0; lag persists/reproduces even with clean logs, disabled plugin bundles, ambient suggestions off, and runtime CPU containment.

This matters because the issue did not start with weak hardware or ordinary machine load; it began suddenly around June 12 after Codex had previously been usable on this same laptop.

Additional evidence submitted: the user has now recorded and sent a Codex performance trace through the in-app feedback/reporting flow for this same regression.

This trace should correspond to the same Windows Desktop input-lag / main-GPU-renderer CPU burst behavior described above and the already-linked session ID:

019ed4e1-678b-7eb0-b47f-fdc9d387f24f

I do not have a separate trace ID to include here, but wanted to note that a performance trace has been submitted so maintainers know to look for it alongside the in-app feedback/session context.

Follow-up as of June 25, 2026:

This is still unresolved and Codex Desktop is still effectively not usable for me on Windows because of the same system/input-lag behavior described above.

Current local app version now installed:

• OpenAI.Codex 26.616.10790.0

So this is no longer limited to the original 26.611.8604.0 build I filed against. I have seen multiple Codex app updates since this report was opened, but the core problem remains: opening/using Codex Desktop can still make mouse movement and typing lag badly on a high-spec Windows laptop.

Current impact:

• I have been virtually unable to use Codex Desktop normally since June 12, 2026.
• I have had to move work into VS Code / CLI fallback workflows because the Desktop app is not reliable enough for normal interactive use.
• This machine should not be near the threshold for basic Codex UI responsiveness: Windows 11, i9-14900HX, 32 GB RAM, RTX 4070 Laptop GPU, AC processor max restored to 100%.
• Earlier local mitigations did not solve it: clean/rotated logs, disabled plugin bundles, ambient suggestions off, node_repl removal, process priority/affinity containment.
• A performance trace was submitted through the in-app feedback flow and the related session ID is already posted above: 019ed4e1-678b-7eb0-b47f-fdc9d387f24f.

I am also concerned because there are several related Windows/Desktop performance reports around the same period, including #27394, #28440, and #28735, and some are closed/duplicated while this current report has no visible maintainer response yet.

Can someone from the Codex team please confirm whether this Windows Desktop performance regression is being actively investigated, and whether there is a recommended workaround, rollback path, diagnostic channel, or canonical tracking issue users should follow? Right now the practical result is that the Desktop app is unusable for affected Windows users even on machines with plenty of CPU/GPU/RAM headroom.

I can reproduce what looks like the same issue on Windows: opening/creating a new Codex thread for the first time in the session can freeze my entire desktop for several seconds, not just the Codex UI.

I collected a 75s trace with a PowerShell sampler + WPR. The system-wide sampler itself was delayed repeatedly:

13:20:34   LoopLagMs: 5924
13:21:01   LoopLagMs: 5547
13:20:47   LoopLagMs: 5183
13:20:50   LoopLagMs: 3095

At the largest stall, the machine was not obviously resource-saturated:

CPU_Total:       26%
DiskQueue:       0
AvailableMem_MB: 12469
Disk_MBps:       15.964
GPU:             basically idle

The suspicious part was kernel/driver activity:

Interrupts_s: 156731
DPCs_s:        6536

So this does not look like normal CPU/GPU/RAM/disk exhaustion. It looks more like Codex is triggering system-wide latency.

The process diff during the repro showed lots of Codex-related Node process churn under the same parent process:

C:\Program Files\nodejs\node.exe ./mcp/server.mjs --stdio

and many:

C:\Users\<redacted>\AppData\Local\OpenAI\Codex\runtimes\cua_node\...\bin\node_repl.exe

These were created repeatedly during the freeze window.

The event log also showed Codex sandbox/profile activity around the same time:

C:\Users\CodexSandboxOffline\NTUSER.DAT

I also tested Microsoft Defender exclusions for Codex-related paths/runtime files, and they did not fix or noticeably reduce the freeze. So Defender might amplify some traces, but it does not seem to be the root cause.

Current hypothesis:

Opening a new Codex thread
→ Codex initializes local runtime / MCP / sandbox infrastructure
→ many node.exe / node_repl.exe workers are spawned
→ Codex touches sandbox/profile/runtime state
→ interrupts/DPCs spike
→ whole desktop stalls for 3–6 seconds

Practical impact update as of 2026-06-30:

I have only been able to use Codex through the terminal/CLI because Codex Desktop is still too laggy to use normally on Windows.

This is not just a slightly slow UI. When Codex Desktop is open, mouse and typing responsiveness degrade enough that the Desktop app is not viable for day-to-day work. The terminal/CLI workflow remains usable on the same machine, which points to the Desktop app/runtime path rather than the laptop being underpowered or Codex as a whole being impossible to run.

Current installed Desktop version:

• OpenAI.Codex 26.623.5546.0

Fresh local observation from today:

• lag started when Codex Desktop was opened
• stale Codex CLI processes from the previous day were present, but they were not the user-visible trigger
• after stopping those stale CLI processes, Codex Desktop itself continued to show high app-server CPU, renderer/main/GPU activity, and active logs_2.sqlite / WAL growth
• observed Desktop app-server around 1.8 GB RAM
• observed Desktop app-server consuming about 18 CPU seconds per 10-second sample
• observed logs_2.sqlite around 259-277 MB plus logs_2.sqlite-wal around 93 MB

So this is still an active Codex Desktop Windows performance regression for me on the latest build I have installed, and the only practical workaround remains using CLI/terminal instead of the Desktop app.

Still present in the new ChatGPT app.

Follow-up after the 9 July migration to the unified ChatGPT desktop app: this remains reproducible on Windows in OpenAI.Codex 26.707.3748.0.

At 13:24 AWST today, while the system/input lag was actively occurring, a 15-second read-only sample showed:

• unified ChatGPT/Codex tree: 11 processes, approximately 1.96 GB working set
• 4.063 CPU-seconds, 16.738 MB read, and 6.540 MB written
• adjacent system sample: 15.0% average total CPU, 20.5% maximum, processor queue maximum 3
• separate ChatGPT Classic tree was nearly idle, so it was not the active trigger
• active logs_2.sqlite plus WAL total approximately 420.8 MB

The CLI remains usable on the same machine; the Desktop app causes the system-wide mouse and typing degradation. This is therefore current-build evidence, not only the original June build report.

Current corroborating reports include #31692, #31531, and Discussion #29949.

Please confirm:

1. Which issue is the canonical tracker?
2. Who owns the Windows regression?
3. Which build contains the intended fix, if one exists?
4. What supported workaround, rollback, or additional trace does engineering require?

Adding a sanitized data point from a newer Windows build.

Environment:

• Codex Desktop 26.707.8168.0
• Windows 11 x64
• Microsoft Pinyin / Chinese text input
• approximately 39.7 GB physical RAM

During visible typing lag, a five-second CPU-time sample showed:

• Codex renderer: 3.17 CPU seconds, approximately 63% of one core
• Desktop Window Manager: 3.02 CPU seconds, approximately 60% of one core
• Codex GPU process: 1.84 CPU seconds, approximately 37% of one core
• Codex main process: 0.97 CPU seconds, approximately 19% of one core
• Renderer working set: approximately 500 MB, with approximately 440 MB private

ChsIME, TextInputHost, and ctfmon were effectively at zero CPU during the same observation. The machine still had approximately 23 GB available RAM, and Windows recorded no resource-exhaustion event.

An earlier comparison of idle versus active Chinese typing showed little change in total Codex CPU load: the renderer/GPU/application stack was already hot before typing began. This suggests the IME is more likely exposing or suffering from a saturated UI/compositor path than being the source of the load itself.

Local user names, workspace names, task contents, paths, process command lines, and raw logs have been omitted.

+1 on this, very freezy when switching chats, opening side chats or submitting prompts. It gets notably slower also when there are long running /goals or chats