# Windows desktop app 26.810.4967.0 continuously uses high CPU after update, causing mouse and keyboard input lag

English translation:

What version of the Codex App are you using (From “About Codex” dialog)?

26.810.4967.0

What subscription do you have?

ChatGPT plus

What platform is your computer?

Windows 11 x64, Build 26200.9168

What issue are you seeing?

Windows desktop app 26.810.4967.0 continuously uses high CPU after update, causing mouse and keyboard input lag

Also submitted through the app, Feedback ID: 019fff71-9924-7f30-bb0b-7104743f9536

Environment

• Client: ChatGPT / Codex Windows desktop app
• Version: 26.810.4967.0
• System: Windows x64, Build 26200.9168
• Logical processors: 20
• Reproduction date: August 14, 2026 (UTC+8)

Issue description

After updating to the version above, the client is usually smooth immediately after launch, but after normal use for some time, it becomes noticeably laggy again. When the lag occurs, not only is the application UI sluggish, but mouse movement and keyboard input are also affected.

Completely quitting and reopening the client temporarily restores normal operation, but the issue may recur after about an hour.

Steps to reproduce

1. Update to Windows desktop app 26.810.4967.0.
2. Launch the client and use several tasks normally.
3. The client initially runs normally.
4. After continued use for some time, the mouse, keyboard input, and UI begin to lag noticeably.
5. The lag persists after switching to other tasks or maximizing or restoring the window.
6. Completely restarting the client temporarily resolves the issue, but it later recurs.

Verified diagnostic data

• During the lag, the main ChatGPT process continuously uses approximately 1.3 logical cores.
• 8-second sample: average 132%, peak 152.41%; all 8/8 samples exceeded 100%.
• 45-second sample while switching between tasks: average 133.02%, minimum 112.99%, maximum 153.82%; all 45/45 samples exceeded 100%.
• Total system CPU averaged approximately 14%–18%, so overall system usage was not conspicuously high, but the main ChatGPT process remained under sustained high load.
• During the lag, approximately 6.7 GB of memory remained available; the disk queue was approximately 0.005–0.01; no significant GPU activity was observed.
• The main process working set was approximately 712 MB, with approximately 895 MB of private memory.
• All ChatGPT processes still showed as Responding, but user input was noticeably delayed.

Concurrent log observations

During the lag, the main window log repeatedly showed:

ResizeObserver loop completed with undelivered notifications.

• It was observed 65 times during this launch.
• It occurred 13 times in the minute closest to the peak lag.
• All occurrences came from the primary main window.
• After maximizing/restoring the window, no new instances of this error appeared temporarily, but main-process CPU still remained at approximately 135%. Therefore, this error may be an accompanying symptom of the same UI state loop and not necessarily the sole root cause.

Additionally:

• 429 requests were concentrated only during initial startup and did not continue when the lag recurred.
• Invalid automation 404s occurred only during startup.
• No continuous WebSocket reconnections were observed.
• The Computer Use / node_repl helper processes used almost no CPU and exited on their own; high CPU usage in the main process continued after they exited.

Troubleshooting attempted

1. Completely quit and restarted the client: temporarily recovered, then recurred.
2. After creating backups, isolated Cache, Code Cache, GPUCache, GrShaderCache, ShaderCache, and GPUPersistentCache: after restart, CPU dropped to an average of 3.63% and a peak of 16.93%, but the issue recurred after about an hour.
3. Maximized, restored, and maximized the window again: new ResizeObserver errors stopped appearing, but high CPU usage did not decrease.
4. Switched to another shorter task and remained there for approximately 20 seconds: CPU continued to remain between 113% and 154%, indicating that the issue was not caused by a single long conversation page.
5. Checked old notify / Computer Use configuration: the client automatically restores the same notify on startup; the helper process does not continuously use CPU, and there is currently no evidence that it is the direct source of the high CPU usage.

Expected behavior

After the client has been running for a long time, the main process should return to low CPU usage, and mouse, keyboard, and UI operations should remain smooth without requiring periodic restarts.

Request for the development team to investigate

Please help determine whether Windows desktop app 26.810.4967.0 has a UI state update loop in the main process or main window, focusing on:

• The Electron main window's ResizeObserver / layout update path;
• A global main-process CPU loop that continues after switching between tasks;
• State accumulation that temporarily clears after rebuilding the cache but recurs after running for some time;
• Whether Statsig refresh network failures or global desktop notification error handling could repeatedly trigger UI updates.

If needed, I can provide additional redacted log excerpts and per-second CPU sampling results. To protect privacy, I will not provide complete conversations, account information, complete local paths, or full unredacted logs.

What steps can reproduce the bug?

Feedback ID: 019fff71-9924-7f30-bb0b-7104743f9536

What is the expected behavior?

_No response_

Additional information

_No response_

<!-- codex-issue-translator -->

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

• #38547
• #38510

Powered by Codex Action

Same regression here on Windows x64 after updating today from 26.803.10989.0 to 26.810.4967.0. Restarting does not reliably fix the lag.
Sanitized log comparison:
26.803: 40 errors, 74 warnings, 37 ResizeObserver errors, 0 unknown-conversation lifecycle events.
26.810: 916 errors, 825 warnings, 335 ResizeObserver errors, 567 “turn started/completed for unknown conversation” events.
Memory initially reached approximately 2.17 GB. Trimming the working set reduced the pressure temporarily, but this is not a durable fix. The new unknown-conversation events affect both the primary renderer and avatarOverlay renderer, suggesting a renderer/app-server state synchronization regression.

这个现象可以再区分一下“UI/主进程循环”和“本地 Chrome/插件运行时状态不一致”两层。

我维护了一个独立的 Windows Codex Desktop 恢复/诊断工具 WinBridge Recovery。它能检查当前 AppX 包、用户侧 bundled marketplace/plugin cache、latest、Chrome Native Host、CUA/runtime 等是否存在版本漂移、缺失或重复 reconcile 的本地状态问题；如果发现的是这类问题，只重建用户可写侧状态，并做 staging/校验/回滚，不修改 WindowsApps。

但你这里已经有一个很重要的信号：最大化/还原后 ResizeObserver 不再新增，而主进程 CPU 仍保持约 135%。如果进一步确认 package/cache/runtime 都一致，并且没有持续的 chrome_native_host_cache_reconcile_failed / bundled_executable_relocation_failed，那更像是 26.810 本身的上游主进程循环，WinBridge 不应该宣称能修。

反过来，如果日志里能看到 Chrome/plugin runtime 同步失败并不断重试，那就值得先用 WinBridge 把本地状态一致性排除掉，再把剩余高 CPU 作为纯上游回归提交给维护者。

I can reproduce an additional child-process accumulation issue on the same Windows app build that appears to amplify this system-wide stutter.

Environment

• Codex/ChatGPT Windows desktop app: 26.810.4967.0 (x64 MSIX)
• Windows 11 Pro x64, build 26200
• 8 logical processors, 15.73 GB RAM
• Reproduced 2026-08-14 (UTC+7)

Clean-restart reproduction

1. Fully quit and relaunch the Codex desktop app.
2. Open one local task.
3. Invoke tool-backed operations several times.
4. Inspect direct children of the bundled codex.exe after each operation completes.

The app process started at 22:06:46. New direct-child bundles appeared at 22:07:01, 22:07:50, 22:08:40, and 22:09:51.

Every bundle contained:

• one node_repl.exe
• one code-review-graph.exe serve
• one uvx.exe ... colab-mcp

Their descendants added one uv.exe and three python.exe processes per bundle. At 22:11:55, all four bundles were still alive: 4 node_repl, 4 code-review-graph, 4 uvx, 4 uv, and 12 python.

The three bundle roots were direct children of the bundled codex.exe, not WSL, a user terminal, or another development process.

Longer-session impact

Before the clean restart, the same pattern had accumulated 15 bundles: 45 python.exe, 15 uv.exe, and 15 node_repl.exe. Python used approximately 3.56 GB RAM and uv approximately 759 MB. Available RAM had fallen to 2.48 GB, memory compression was approximately 814 MB, mouse movement was jerky across Windows, and audio crackled while Codex executed tasks.

After terminating only the older duplicate bundles while retaining the newest bundle, available RAM increased to 5.38 GB and memory compression fell to approximately 40.8 MB. The external disk was idle during the symptom.

Sanitized desktop-log counts

In the 2.33 MB desktop log from the affected pre-restart instance:

• Received turn/started for unknown conversation: 36
• Received turn/completed for unknown conversation: 36
• ResizeObserver loop completed with undelivered notifications: 142
• chrome_native_host_cache_reconcile_failed: 0
• bundled_executable_relocation_failed: 0

Expected: tool/MCP runtimes are reused or terminated after their owning session finishes.

Actual: completed operations leave old bundles running, process count and memory pressure grow over time, and restarting Codex clears them only temporarily.

No full logs, conversation transcript, account data, credentials, or complete user paths are included. This may be a separate lifecycle leak that compounds the main-process/UI regression described here.

Additional controlled evidence from the same Windows x64 machine and Codex build (26.810.4967.0):

Reproduction trigger

A local data-heavy task processed 223,951 markets into 189,741 events and ran for approximately 109 minutes. After the task completed and the thread became idle, the desktop and Codex UI still felt less responsive.

Post-task measurements

• System memory remained around 50% with approximately 15.6 GB free; this was not overall memory pressure.
• Over an 8–10 second sample, the ChatGPT/Codex process group used approximately 9.1% of total system CPU and approximately 1.94 GB working set.
• The primary ChatGPT process alone remained around 6.2–6.9% of total system CPU while the task was idle.
• CentBrowser used approximately 1.3% total CPU; WorkBuddy was near 0%, so the lag was not explained by CentBrowser or an active project process.

Child-process cleanup evidence

After the task reported completion, four headless screenshot Chrome processes, one static preview Node process, and one CUA kernel process were still alive. Terminating only these six task-specific processes reduced the main ChatGPT working set from approximately 999 MB to approximately 791 MB, but the primary ChatGPT process remained around 6.9% CPU and the UI was still not fully smooth.

This separates two issues:

1. task/tool child-process lifecycle cleanup is incomplete; and
2. the primary Electron/Chromium renderer remains busy after the task becomes idle.

Expected behavior

When a local task completes, task-owned child processes should be reaped and the primary renderer should return near idle without requiring a full application restart.

Please triage this additional evidence together with #38547 and #38583. A supported soft renderer recovery path would also be valuable while the underlying 26.810 regression is being fixed.

Independent reproduction from another Windows 11 system (user: sanjayshetty).

Codex was updated to 26.810.4967.0 on 2026-08-14. Luna Max had been stable for me throughout August; no model downgrade preceded this regression.

Observed after the update:

• Codex starts normally, then a long-running task makes the app and sometimes the whole machine sluggish.
• In Windows Task Manager, the ChatGPT/Codex group reached approximately 2.6 GB and 34.6% CPU while overall CPU was approximately 88%; individual Codex children included codex.exe at approximately 929 MB and another Codex process at approximately 762 MB.
• Automatic context compaction appeared unusually often, including in tasks that looked new in the UI.
• Closing Codex restored normal machine responsiveness; restarting it helped temporarily.
• OneDrive had a separate memory spike, but after restarting OneDrive its usage dropped. The slowdown returned with Codex, not OneDrive.

I have not attached private logs, paths, account details, or conversation data. This independently corroborates the current-build performance regression and the close/restart boundary. Please link this report with #38547 and check the shared Electron/main-process, renderer, monitoring, and compaction behavior.

Independent A/B evidence from another Windows system running Codex Desktop 26.810.4967.0 (bundled app-server 0.148.0-alpha.9).

The Codex UI and the whole PC, including mouse/input responsiveness, became noticeably laggy after several local tasks. At capture time, completed work was idle and two long-running tasks were not loaded.

Quiet 15-second sample before restart

• Desktop main process CPU: 60.5% of one logical core
• Logical reads: 925.38 MB/s; logical writes: 0.02 MB/s
• Physical disk throughput / queue / busy: 0 MB/s / 0 / 0%
• Free physical memory: 12.35 GB
• Full Codex process tree: 112 processes, 5,670.3 MB working set, 27,910 handles, 1,738 threads
• Root instances of each main configured MCP family: 9

Full-exit/restart A/B result

Fully exiting and restarting Codex immediately restored responsiveness. In the comparable post-restart sample:

• Main-process CPU: 0.0%
• Logical reads: 0.00 MB/s
• Process tree: 48 processes, 3,263.3 MB working set, 14,094 handles, 898 threads
• Root instances of each main MCP family: 3 (down from 9)

The three-suite post-restart baseline remained stable. One additional controlled code-mode call did not create a fourth suite, so this does not support the claim that every code-mode call leaks a suite. However, six excess MCP suites and the sustained main-process logical-read activity were both cleared by restart.

Sanitized desktop-log signals before restart

• Received ... for unknown conversation: 1,462
• Conversation state not found: 477
• ResizeObserver loop completed with undelivered notifications: 307

The unknown-conversation/state counters stopped increasing before the final quiet sample, while the logical-read loop continued. They may be evidence of lost UI/conversation state rather than the sole direct cause.

The strongest supported finding is unreclaimed resource/state accumulation over the desktop-app lifetime. The exact ownership/lifecycle path still needs product-side tracing. The measurements do not support RAM exhaustion, paging pressure, physical-disk saturation, or loaded long-chat context as the cause.

This comment intentionally excludes prompts, transcripts, project content, account details, credentials, local paths, and raw logs.

My mouse cursor started dropping frames and lagging shortly after the client was opened.

Additional observation that may help narrow this down: an active Codex task does not appear to be required.

On Windows, Codex Desktop can reproduce the system-wide mouse/keyboard stutter while completely idle—no task, agent, repository operation, or user-requested work is running. After being left open for a while, Task Manager shows the ChatGPT/Codex process group sustaining roughly 8–10% CPU.

During one occurrence:

• ChatGPT.exe PID 25692: ~7–8% CPU; CPU time continued rising from 00:21:38 to 00:24:40 while idle.
• codex.exe PID 21864: ~0% CPU; CPU time ~00:00:11.
• GPU ~0–2%, disk ~0%, memory ~38–41%.

Fully exiting Codex immediately restores normal system responsiveness. Restarting it temporarily resolves the issue, but the stutter can return after another idle period.

This suggests the issue may originate in a ChatGPT.exe host/renderer/background busy loop rather than an active Codex task.

https://github.com/openai/codex/issues/38716#issuecomment-5302760473

Additional root-cause evidence from an independent Windows 11 reproduction using ChatGPT/Codex Desktop 26.810.4967.0:

The stutter appears to be caused by the Chrome native-host/plugin cache watcher entering a self-triggering reconciliation loop.

During the stutter:

• Main ChatGPT.exe: ~133% CPU on a one-core scale.
• Logical reads: ~1,155 MB/s with almost no writes.
• Private memory oscillated around 0.6–1.3 GB.
• GPU, DPC/ISR, physical-disk pressure, and the mouse driver were normal.
• Mouse-event gap p99 was ~468 ms, with a maximum of ~810 ms.
• The chrome\latest cache junction was repeatedly deleted and recreated; its parent generated approximately 3.6 change events per second.

Static inspection suggests that the watcher reacts to changes caused by its own cache synchronization. Each pass compares and hashes the same large source/destination binaries—approximately 695.5 MB of reads per round. At roughly 1.82 rounds per second, this predicts ~1.27 GB/s of logical reads, closely matching the measured ~1.29 GB/s.

A likely contributing factor is Windows path normalization: the marketplace path uses the \\?\ form while the junction target resolves to an ordinary drive path. A strict string comparison may therefore treat an already-correct junction as stale and recreate it indefinitely. This is an inference from the packaged application behavior and observed filesystem events.

Controlled A/B result:

• Removing the ChatGPT browser extensions and the Codex chrome@openai-bundled plugin stopped the loop.
• After restart: CPU ~3.9%, logical reads ~0.04 MB/s, zero junction changes, and no extension-host process.
• After complete removal, the plugin cache, native-host registry entry, and native-host manifest were absent, and mouse movement remained smooth.

Suggested fixes: canonicalize Windows paths before comparison, prevent the watcher from reacting to its own junction updates, add reconciliation debouncing/reentrancy protection, and avoid rehashing unchanged large binaries.

No conversations, account information, credentials, complete local paths, or raw logs are included.

Update after controlled testing on Windows with 26.810.7004.0:

Status: partially resolved

• ✅ The severe system-wide mouse/input stutter that I observed on 26.810.4967.0 no longer reproduces. The main high-CPU / high-read-loop portion appears to be fixed in 26.810.7004.0.
• ❌ The separate child-process lifecycle/retention issue described in my earlier comment is still reproducible.

Controlled built-in-only A/B test

I temporarily disabled only my two external MCP server entries, code-review-graph and colab-mcp, with enabled = false, then performed a clean application restart. This removed CRG, uvx, uv, and Python from the test path.

Observed direct children of the bundled Codex app-server:

1. Immediately after restart: 1 bundled node_repl.exe
2. After ordinary Codex/app operations, before the explicit probe: 4
3. After five separate built-in node_repl calls: 5
4. After 60 seconds idle: all 5 processes were still alive; the older instances were not cleaned up

During a five-second CPU sample, these five retained processes were idle (0 CPU delta) and used approximately 44.6 MB total working set. This explains why the mouse currently remains smooth despite the retained processes.

This controlled test demonstrates built-in process multiplicity and idle retention without CRG, uvx, uv, or Python involved. It does not by itself prove unlimited growth, but it isolates the process owner/lifecycle to the bundled Codex app-server rather than the external MCP implementations. With external MCPs enabled, each retained scope can also keep their descendant processes, which amplifies memory and process count over a long session.

I restored the original MCP configuration after the test and restarted the app.

Therefore, please treat my earlier report as partially resolved, not fully resolved:

• main stutter/high-CPU symptom: fixed in 26.810.7004.0
• helper-process lifecycle/cleanup: still unresolved and likely related to #37672

Additional reproduction from another Windows 11 system:

• Codex Desktop: 26.810.4967.0 (the issue began after the Aug 14 update from 26.803.10989.0).
• Windows 11 x64, build 26200; Dell OptiPlex 3080, Intel Core i5-10500, Intel UHD 630.
• The app remained smooth for about 1.5 hours after a clean restart. Merely opening the in-app Settings page then reliably triggered severe system-wide mouse-pointer stutter. Leaving Settings did not recover it; fully quitting Codex stopped the lag.
• During the incident, the main ChatGPT.exe process sampled at 130.6% CPU with ~695.5 MB working set and 62 threads. The GPU process was ~7.5%, and the busiest renderer was ~5.3%.
• The app telemetry repeatedly logged the same error between 13:53:01 and 13:56:09 local time:

[electron-message-handler] [desktop-notifications][global-error] ResizeObserver loop completed with undelivered notifications.

• No contemporaneous Windows display-reset, GPU-reset, DWM crash, or renderer-crash events were found.
• The Codex package reports Status OK. Re-register/Repair completed successfully with data preserved.
• The Intel graphics driver was updated from 27.20.100.9664 to 31.0.101.2114 and rebooted/retested, but the Settings-triggered CPU loop still reproduced.

This makes Settings a concrete trigger for the same persistent main-process loop. Restarting Codex is only a temporary workaround; avoiding Settings prevents the immediate reproduction.