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

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

Start from Codex Desktop on Windows with clean/small local logs.
Update Codex Desktop from 26.611.8273.0 to 26.611.8604.0.
Reopen Codex Desktop.
Open/continue an existing local Codex thread.
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:

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.

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

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:

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.

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:

June 12, 2026: first user-visible performance regression begins; local log data also shows a major spike that day.
June 17-18, 2026: additional spikes / renewed troubleshooting.
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:

Which issue is the canonical tracker?
Who owns the Windows regression?
Which build contains the intended fix, if one exists?
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

Adding a sanitized data point from the July 23/24 unified ChatGPT/Codex desktop rollout.

Environment

Date reproduced: 2026-07-24
Desktop package: OpenAI.Codex 26.721.3996.0
OS: Windows 10 Home, build 19045, x64
CPU: Intel Core i7-7700, 4 physical / 8 logical processors
RAM: approximately 32 GB
GPU: Intel HD Graphics 630, driver 26.20.100.8142

User-visible behavior

After the recent desktop update, the unified ChatGPT/Codex process group repeatedly holds roughly 18-20% of total system CPU while the Codex view is open, including periods with no task actively running.
Sending a prompt can spike it higher; it may settle after prolonged inactivity, but rises again during normal work and tends to worsen over the course of a working day.
Mouse movement and typing become slow, delayed, or intermittently unresponsive across Windows, not only inside the Codex window.
A full reboot temporarily reduced the load, but the problem returned.
Closing Chrome and minimizing Codex did not materially change the Codex CPU baseline.

Fresh 10-second process sample

Captured while using this issue-reporting thread on build 26.721.3996.0:

embedded codex.exe app-server: 41.5% of one logical core
busiest ChatGPT renderer: 40.6% of one logical core
ChatGPT GPU process: 20.1% of one logical core
ChatGPT main process: 15.9% of one logical core
secondary renderer: 6.1% of one logical core
combined active app processes: approximately 124% of one core, equivalent to about 15.5% of total capacity on this 8-logical-processor machine
all observed node.exe and node_repl.exe processes: 0.0% during the same sample

Earlier sampling during the same regression also showed elevated ChatGPT GPU-process and Desktop Window Manager activity, consistent with renderer/compositor pressure.

Negative findings / ruled-out paths

Approximately 17-19 GB physical RAM remained available during diagnostic samples.
Processor queue was zero and disk queue averaged approximately 0.01; disk throughput was negligible.
DPC and interrupt utilization remained low; no USB reset storm was present.
SQLite integrity checks passed. Current state migrations/backfill completed successfully, and database/WAL activity did not track the sustained CPU load.
The active repository was clean: zero untracked or modified files. A short high-frequency process watch observed no git.exe activity, so the recently discussed untracked-file/Git polling loop does not explain this reproduction.
MCP/Node children were present but idle, so Node process count alone does not explain this sample.

The recurrence coincided with the unified desktop update and the subsequent Voice-in-Work/Codex rollout. This is only a timing correlation; I am not claiming the voice engine itself is the proven cause.

This appears to be the same Windows desktop main/renderer/GPU/app-server regression already tracked here, now reproduced on 26.721.3996.0. Please confirm the canonical tracker, whether a fix build or supported workaround exists, and what additional trace would be most useful.

Local usernames, paths, hostname, repository/task contents, process IDs, and raw logs have intentionally been omitted.

Additional current-build Windows reproduction and diagnostic A/B

Fresh in-app feedback/session ID: 019f67a5-a5e3-7122-9590-672a89dabc69

Environment and impact

Windows 11 x64
Current Microsoft Store package: OpenAI.Codex 26.727.6591.0
6-core Intel CPU, 32 GB RAM, Intel integrated graphics plus NVIDIA discrete graphics
Severe system-wide mouse and typing stutter, worst after Desktop launch and while opening or switching projects/tasks, with additional bursts during normal use

The problem predates the current build and has reproduced across multiple Desktop releases. It affects pointer/input responsiveness outside the Codex window. Task Manager often shows no saturated CPU, GPU, memory, or disk component. Earlier unmodified WPR/ETW and PowerShell captures found scheduler/dispatch latency while DPC, interrupt, and disk activity remained too low to explain the stalls, with no timestamp-correlated WHEA, display-driver, or disk error.

App-specific findings

With the pet disabled in Settings, stock Desktop builds still created an invisible avatarOverlay renderer. Historical logs showed that renderer issuing skills/list approximately every 10 seconds. It could also resume an unrelated task and reread its rollout history.
A controlled Remote Control A/B produced a much stronger signal. With the macOS Codex client still open after navigating away from a Windows-hosted task, the Windows launch created a second app-server request connection, resumed that unrelated task, and reread all 4,066 rollout items 16 times in approximately 24 seconds. After fully quitting the macOS client and changing nothing else, the next Windows launch produced zero second-connection requests and zero corresponding resume/history events for 157 seconds.
Every heavily affected project root checked in this investigation was not a Git repository. ETW did capture repeated Codex FileCreate probes for candidate git.exe locations, but no git.exe execution or branch comparison. Therefore the multi-million-line branch-diff mechanism in About high CPU and severe UI input lag #36752 does not appear to be the primary cause here, although repeated Git discovery may be an amplifier.

These findings overlap directly with #21211 (eager/repeated history hydration) and #33236 (skills/list blocking task navigation).

Important caveat about this feedback capture

This specific feedback session was launched with a local, version-pinned NODE_OPTIONS preload mitigation. It does not alter the installed MSIX, and the launcher restores NODE_OPTIONS immediately after startup. The preload blocks hidden avatarOverlay and globalDictation windows; suppresses or serializes automatic history hydration; defers non-due heartbeat resumes; caches repeated skills/list requests; bypasses sidebar Git-origin discovery; and suppresses automatic bundled-plugin reconciliation and child-process telemetry sampling.

Consequently, logs attached to this feedback reflect mitigated behavior. Reduced or absent hidden-renderer, hydration, Git-discovery, plugin, or telemetry events in this session must not be interpreted as proof that the stock build is fixed. The original symptom and the earlier traces predate the mitigation and were reproduced without it.

Requested investigation

Keep pointer/input and task navigation responsive while startup, skill discovery, and history loading continue in the background.
Do not construct or subscribe hidden feature renderers when the corresponding pet/dictation feature is disabled.
Deduplicate and bound remote/background task hydration, and release remote task state when a remote client navigates away or disconnects.
Expose enough request-source information in diagnostics to distinguish the visible task, hidden renderers, and remote clients.

Still reproducible on Windows 11 with OpenAI.Codex 26.810.4967.0.

The Windows AppX deployment log records an automatic preferred-package switch from 26.803.10989.0 to 26.810.4967.0 on 2026-08-14 at 11:16:49 CEST. Immediately after that update, opening the desktop app causes system-wide mouse and keyboard stutter, including with a completely new empty chat. Fully terminating the ChatGPT/Codex desktop process tree restores normal responsiveness immediately; reopening the app reproduces the lag.

Overall CPU, RAM, and disk were not saturated during reproduction, and no logical processor remained pinned at 100%. This regression therefore appears to persist in the current Windows build.

Adding a privacy-sanitized current-build reproduction with Windows resource-leak evidence.

Environment

Reproduced twice on Windows 11 x64
Unified Codex/ChatGPT Microsoft Store package: OpenAI.Codex 26.810.6296.0

User-visible behavior

While using a long Codex thread, the mouse pointer began freezing/stuttering across the entire Windows desktop, not only inside the Codex window. This has happened twice; the first occurrence led to a PC restart.

During the second incident, fully closing only the unified ChatGPT/Codex desktop app restored normal pointer responsiveness immediately. No reboot or other process termination was required.

Live measurements during the incident

An 8-second process sample showed the hottest ChatGPT.exe process at:

approximately 147.7% of one logical core (12.3% normalized total CPU on this machine)
approximately 965 MB working set
approximately 1.18 GB private memory
56 threads

The machine was not resource-saturated:

total CPU averaged approximately 25.7%, maximum approximately 41.2%
approximately half of physical memory remained free
disk queue was 0, with effectively no disk activity in the sample
observed GPU engines remained below approximately 5%
DPC and interrupt utilization remained low
no timestamp-correlated display, storage, or WHEA errors were present

Other active applications were not comparably hot, and closing them was not required. Full exit of ChatGPT.exe was the action that immediately ended the system-wide pointer lag.

Windows Error Reporting evidence

Windows Application event log independently recorded a resource-leak warning for the affected process:

Event Name: RADAR_PRE_LEAK_64
Process: ChatGPT.exe

Unique WER identifiers, hardware identifiers, local paths, raw logs, project details, and private thread contents are intentionally omitted from this public comment.

The combination of (1) reproduction on the current build, (2) a hot ChatGPT.exe process retaining about 1.18 GB private memory, (3) Windows independently flagging RADAR_PRE_LEAK_64, and (4) immediate recovery on full app exit suggests a unified-desktop renderer/resource-retention path rather than ordinary whole-system saturation.

Stock 26.810 reproduction: repeated full-history reconstruction and Remote amplification

Fresh in-app feedback was resubmitted from this stock, unmodified session:

019f67a5-a5e3-7122-9590-672a89dabc69

Environment:

Windows 11 x64
Microsoft Store package OpenAI.Codex 26.810.4967.0
Desktop client 26.810.41047
No preload launcher, modified application assets, or mitigation patch active

A fresh launch with both the macOS and iPhone Remote clients completely quit still produced:

66 thread/turns/list requests
7 thread/resume requests
72 completed rollout reconstructions
multiple reconstructed histories ranging from hundreds to 13,576 items
the visible 13,576-item task reconstructed 29 times in approximately 18 seconds

All requests in this disconnected launch used the local Desktop app-server connection. The storm stopped approximately 46 seconds after process startup, matching the user-visible startup lag eventually settling.

With macOS and iPhone clients connected to tasks hosted by the Windows client, the same input stutter became dramatically worse and did not settle: mouse and keyboard input across the desktop was staggered and delayed until the Windows app was completely exited. Fully quitting both Remote clients before restarting Windows Codex restored the shorter, self-terminating baseline above.

Therefore Remote is not required to trigger the defect. The local Windows client independently performs repeated full-history reconstruction, while Remote connection/state activity appears to amplify or prolong the same refresh cycle.

During a follow-on capture, the main ChatGPT.exe process averaged approximately 19.5% of total six-core CPU and reached a 1.26 GB working set. DPC, interrupt, disk-latency, and GPU measurements remained too low to explain the system-wide stalls.

Task size increases the cost of each unnecessary reconstruction but does not explain why unchanged histories are requested and rebuilt repeatedly. Please deduplicate and bound thread/turns/list, avoid rebuilding complete rollouts on repeated UI invalidation, and ensure Remote connection/background/disconnect events cannot perpetuate local task hydration.

Adding a privacy-sanitized reproduction on the current Windows build, with local-state measurements that may help narrow the trigger.

Version transition and trigger

Microsoft Store package updated from OpenAI.Codex 26.803.10989.0 to 26.810.4967.0.
The system-wide mouse stutter began after the update and is reproducibly triggered when resuming an existing tool-heavy workflow.
The cursor can stutter outside the Codex window. It may settle temporarily, then return when workflow activity resumes.

Live measurements during lag

A 10-second sample showed:

Electron/ChatGPT main process: approximately 119.2% of one logical core
GPU child: approximately 23.4% of one logical core
renderer child: approximately 17.3% of one logical core
DWM 3D engine: approximately 12.8% average
ChatGPT GPU 3D engine: approximately 7.3% average

The machine was not globally saturated:

DPC time: 0.33% average, 1.00% maximum
interrupt time: 0.34% average, 0.96% maximum
processor queue length: 0.10 average, 1 maximum
no timestamp-correlated display-driver, WHEA, storage, or device errors

Local-state scale

Metadata-only inspection, without reading or sharing task contents, found:

logs_2.sqlite: approximately 415 MB
retained log rows: 265,281
WAL: approximately 6.5 MB
session artifacts: approximately 2.67 GB across 454 files
82 session artifacts larger than 10 MB
largest session artifact: approximately 424.8 MB
most recently active session artifact during reproduction: approximately 38.4 MB

During the same capture, the main process reached about 1.08 GB working set and the primary renderer about 620 MB.

Negative checks

no taskkill.exe or git.exe process storm
DWM handle count stayed stable at approximately 2,213 through several additional tool calls, so the immediate incident did not show the progressive DWM-handle signature from [Windows 10] DWM Composition handles accumulate after Codex tasks with tool calls #33192
kernel interrupt/DPC and disk behavior remained too low to explain the input stalls

This looks consistent with repeated/full-history hydration or reconstruction becoming expensive in the current renderer/main-process path, amplified by oversized retained log/session state. The task size explains the cost, but not why unchanged history appears to be rebuilt often enough to affect system-wide input.

No raw logs, local paths, task contents, usernames, hostnames, hardware identifiers, dump files, or session IDs are included.

I have a new Windows reproduction that appears closely related, with a version-specific before/after capture.

Environment

Windows x64, build 26200.9168
Lenovo ThinkBook 16p Gen 4 IRH
32 GB RAM
Hybrid graphics: Intel Iris Xe + NVIDIA RTX 4060 Laptop GPU
Microsoft Store Codex/ChatGPT desktop app

User-visible behavior

The mouse cursor and window dragging became intermittently laggy across the Windows desktop. The issue stopped immediately after fully quitting and reopening Codex. Restarting Windows was not required for this recurrence.

Fault capture

The affected running desktop build reported:

buildVersion=26.810.6296.0

while the installed Store manifest/update path already reported:

manifestBuildVersion=26.810.7004.0

During a 61-second live fault sample, the Codex/ChatGPT desktop main process showed:

CPU delta: 78.92 CPU seconds in about 61 seconds (~1.29 logical cores on average)
Working set: 870.5 MiB -> 1152.2 MiB (+281.7 MiB)
Private memory: 811.7 MiB -> 1277.4 MiB (+465.7 MiB)
Handles: essentially stable (2217 -> 2215)
Process still reported Responding=True

Other system measurements during the same fault sample did not show saturation:

Total CPU average: 14.38%
DPC average / max: 0.63% / 1.88%
Interrupt average / max: 0.32% / 0.53%
Disk busy average / max: 1.47% / 3.42%
NVIDIA GPU average / max: 16.26% / 26%
NVIDIA power average: 2.92 W
DWM CPU average: 4.37%

This recurrence therefore looked like a Codex desktop main-process CPU/memory runaway rather than GPU saturation, DPC/ISR pressure, disk saturation, or an input-device problem.

Controlled recovery / update transition

After fully quitting and reopening Codex, the active Microsoft Store package was 26.810.7004.0 (Status=Ok, Store signed), and the system-wide cursor lag was gone.

In a 20-second post-restart check, the new desktop main process showed:

CPU delta: 0.62 CPU seconds
Working-set delta: -1.8 MiB
Private-memory delta: -1.1 MiB
NVIDIA GPU: P8, about 3-4 W

No related Application Error, Application Hang, Display, nvlddmkm, igfx, DxgKrnl, WHEA, or Windows Error Reporting event appeared after the restart.

Desktop log signals

The old main-process log contained repeated frontend-state/layout messages such as:

Conversation state not found
Received turn/... for unknown conversation
ResizeObserver loop completed with undelivered notifications
events delivered to a hidden avatarOverlay WebContents

However, a smaller number of similar messages also occur after restart while resource use remains normal, so I am treating them as correlated signals rather than a proven root cause.

Current status

The issue has not yet recurred on 26.810.7004.0. I will add another fault capture if it does. The useful new evidence here is the paired main-process CPU/private-memory growth on 26.810.6296.0 and the clean post-restart state after switching to 26.810.7004.0.

I can provide additional sanitized counters or a redacted desktop-log excerpt if a maintainer identifies the preferred fields. Raw logs/traces are not attached because they contain local paths and may contain sensitive session metadata.

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

Description

What issue are you seeing?

Environment

Steps to reproduce

Expected behavior

Actual behavior

Evidence collected

Mitigations / A-B checks tried

Additional observation

Related issues found before filing

Logs / session sharing

Activity

github-actions commented on Jun 18, 2026

Yassycodes commented on Jun 18, 2026

Yassycodes commented on Jun 18, 2026

Yassycodes commented on Jun 18, 2026

Yassycodes commented on Jun 18, 2026

Yassycodes commented on Jun 18, 2026

Yassycodes commented on Jun 25, 2026

leanderriefel commented on Jun 29, 2026

Yassycodes commented on Jun 30, 2026

leanderriefel commented on Jul 9, 2026

Yassycodes commented on Jul 10, 2026

loraldx commented on Jul 13, 2026

Altair200333 commented on Jul 16, 2026

heithmurray commented on Jul 24, 2026

Environment

User-visible behavior

Fresh 10-second process sample

Negative findings / ruled-out paths

AlarmingMelon commented on Aug 3, 2026

Additional current-build Windows reproduction and diagnostic A/B

Environment and impact

App-specific findings

Important caveat about this feedback capture

Requested investigation

janis-hau commented on Aug 14, 2026

joaobzrra commented on Aug 14, 2026

Environment

User-visible behavior

Live measurements during the incident

Windows Error Reporting evidence

AlarmingMelon commented on Aug 15, 2026

Stock 26.810 reproduction: repeated full-history reconstruction and Remote amplification

anotb commented on Aug 15, 2026

Version transition and trigger

Live measurements during lag

Local-state scale

Negative checks

PatrickChen-Canton commented on Aug 17, 2026

Environment

User-visible behavior

Fault capture

Controlled recovery / update transition

Desktop log signals

Current status

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions