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

[Yassycodes]

What issue are you seeing?

Codex Desktop on Windows causes intermittent whole-system input lag, especially immediately after launch/reopen and during later bursts. Mouse movement and typing become visibly laggy while Codex is open. The same machine otherwise handles heavier workloads normally.

This reproduced after Codex Desktop updated from 26.611.8273.0 to 26.611.8604.0.

This appears different from the earlier local logs_2.sqlite bloat problem: after clearing/rotating logs and reproducing on 26.611.8604.0, the log DB stayed small while Codex Desktop/Electron main/GPU/renderer processes continued to spike CPU.

Environment

• Platform: Windows desktop app from Microsoft Store
• Codex before update: OpenAI.Codex 26.611.8273.0
• Codex after update: OpenAI.Codex 26.611.8604.0
• Install path after update: C:\Program Files\WindowsApps\OpenAI.Codex_26.611.8604.0_x64__2p2nqsd0c76g0
• Machine has 32 logical processors
• AC processor max state was verified/restored to 100%

Steps to reproduce

1. Start from Codex Desktop on Windows with clean/small local logs.
2. Update Codex Desktop from 26.611.8273.0 to 26.611.8604.0.
3. Reopen Codex Desktop.
4. Open/continue an existing local Codex thread.
5. Observe mouse/typing lag immediately after launch/reopen and intermittently afterward.

Expected behavior

Codex Desktop should remain responsive enough that mouse movement and typing do not lag system-wide, especially on a high-spec Windows machine, even while opening a thread or doing background startup/reconnect work.

Actual behavior

Codex Desktop causes intermittent system input lag while open. The lag is worst on launch/reopen, can settle, then later recurs in bursts.

Evidence collected

A controlled update watch captured the package changing from 26.611.8273.0 to 26.611.8604.0 around 2026-06-18 12:47 AWST.

Before the update watch, a separate issue was found and mitigated:

• %USERPROFILE%\.codex\logs_2.sqlite had grown to about 1.56 GB
• %USERPROFILE%\.codex\logs_2.sqlite-wal had grown to about 174 MB
• Read-only SQLite query showed 232,280 retained log rows
• Moving logs_2.sqlite* aside while Codex was closed allowed Codex to recreate clean logs and temporarily improved responsiveness

After updating to 26.611.8604.0 and reproducing the lag:

• logs_2.sqlite stayed around 15.98 MB
• logs_2.sqlite-wal stayed around 7.77 MB
• Log growth did not explain the renewed lag

During active lag after the update, a 10-second CPU delta showed:

• Codex.exe process using about 81.4% of one core
• another Codex.exe process using about 38.8% of one core
• another Codex.exe process using about 20.2% of one core
• codex.exe app-server using about 4.2% of one core

A faster 2-second burst sampler observed:

• combined Codex/codex/node CPU bursts up to about 200% of one core
• single Codex renderer bursts up to about 100% of one core
• log files stayed small during these bursts

A later recurrence showed:

• main/high-memory Codex.exe process around 81.2% of one core
• GPU-process Codex.exe around 37.5% of one core
• renderer Codex.exe around 12.1% of one core
• codex.exe app-server --analytics-default-enabled around 6.2% of one core

Mitigations / A-B checks tried

• Restored AC processor max state to 100%
• Disabled all always-on plugin bundles
• Prevented full-home-folder scans in local Codex instructions
• Rotated the huge logs_2.sqlite* files so Codex recreated clean logs
• Temporarily set ambient-suggestions-enabled = false
• Removed active node_repl MCP block before restart
• Set Codex/codex processes to BelowNormal, then Idle
• Restricted Codex/codex processes to 4 of 32 logical processors
• Killed only the Electron GPU child process so Electron could respawn it, then re-applied the guard

Result: lag still reproduced. Runtime priority/affinity containment did not fully protect system input responsiveness.

Additional observation

After removing the active [mcp_servers.node_repl] block before restart, Codex appeared to reintroduce an active node_repl MCP block on launch/update while a disabled copy also remained. However, during lag, the main measured CPU pressure came from Codex.exe main/GPU/renderer processes rather than node_repl.exe.

Related issues found before filing

This appears related to prior performance reports, but the version/timeline and the clean-log reproduction look specific enough to file separately:

• Codex App frequently freezes/stutters on Windows 11 Pro despite sufficient system resources #20214
• Codex Desktop sluggish after today's update to 26.429.20946 #20547
• Codex App 26.429.61741 causes persistent high CPU usage in renderer and severe UI lag on macOS #21326
• Codex Desktop rapidly grows logs_2.sqlite / WAL during normal active use #24275
• Desktop launch can fail when logs_2.sqlite grows large: app-server SQLite pool times out during startup #27741

Logs / session sharing

The troubleshooting page says to use in-app / feedback and share the resulting session ID. I have not included raw local logs/config here because they may contain sensitive local paths or tokens. Sanitized evidence summaries are available, and a feedback/session ID can be added if needed.

[github-actions]

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

• Codex Desktop Windows 26.611.61753: chat switching and composer typing feel laggy #28735
• Windows codex desktop renderer process CPU hogging #28440
• High CPU usage after update. #27394

Powered by Codex Action

[Yassycodes]

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.

[Yassycodes]

Reviewed the potential duplicates suggested by github-actions:

• Codex Desktop Windows 26.611.61753: chat switching and composer typing feel laggy #28735 is related but was for 26.611.61753, focuses on chat switching/composer typing latency, and is already closed.
• High CPU usage after update. #27394 is related but was for 26.608.12217 and is also closed.
• Windows codex desktop renderer process CPU hogging #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.

[Yassycodes]

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.

[Yassycodes]

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.

[Yassycodes]

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.

[Yassycodes]

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.