Task switching causes system-wide stuttering #33382

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   performance

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   on Jul 15, 2026
2. github-actions commented on Jul 15, 2026

   

   github-actionsbot

   on Jul 15, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Windows Codex app causes mouse stutter during startup and task switching without CPU/Disk saturation #33074
   • [Windows App] Repeated serialport.node delay-load failures cause severe UI lag #33375

   Powered by Codex Action
3. STHONEONE commented on Jul 16, 2026

   

   STHONEONE

   on Jul 16, 2026 – with ChatGPT Codex Connector

   More actions

   Additional independent reproduction on Windows x64, build 26200.8875, Codex Desktop 26.707.9981.0 / Chromium 150.0.7871.115.

   I see the same task-switch stutter and MoAppCrash, plus a second deterministic trigger: closing a permission prompt with Allow once.

   Controlled measurements:

   • Across 6 real sidebar task switches, completion latency ranged from about 6.8 s to 29.9 s. The Codex backend process reached about 96% P95 of one logical core; the ChatGPT UI process reached about 56% P95, versus roughly 38% in the idle baseline.
   • During a controlled Allow once action, the ChatGPT UI process reached about 99% P95 of one logical core, the backend reached about 100% P95, and the UI working set increased by roughly 40 MB.
   • In a complete app-log/WER correlation window, there were 20 requestApproval accept events. 20/20 were followed 0.520–1.921 seconds later by Windows Application Error 1000 / MoAppCrash for ChatGPT.exe, exception 0xc06d007f, faulting module unknown. The app remained open, so this appears to be a recoverable crash-class/native error path rather than a full visible restart.
   • One task switch emitted 13 thread/list requests in 592 ms, followed by resume/read work. In the same log, thread/resume took as long as 62.814 s, and turns/list as long as about 12 s. Duplicate skills/list and config/read calls were also present.
   • Short and medium tasks still saturated approximately one core during switching, so long histories amplify the issue but do not appear to be the sole cause. The current history was about 89 MB; the largest local history was about 246 MB.
   • I found no matching display-driver reset (Event 4101), App Hang 1002, DWM error, renderer-process-gone, GPU-process crash, OOM, or SQLite busy/locked evidence.

   The permission-close correlation may help narrow this beyond transcript rendering. There are also repeated unknown conversation / orphaned-response events duplicated to the primary window and avatarOverlay, which may be an amplifier rather than the root cause.

   Possibly related root-cause report: #33375. I am not attaching raw session files or dumps publicly because they may contain private content, but can provide sanitized/private diagnostics if a maintainer requests them.
4. HeyDachui commented on Jul 16, 2026

   

   HeyDachui

   on Jul 16, 2026 – with ChatGPT Codex Connector

   More actions

   I can independently reproduce the same high-frequency WER activity on the x64 build, with one important distinction: the main process can remain alive and responsive while Windows repeatedly records Event 1000 and writes large local dumps.

   Environment

   • Windows 11 Pro x64, build 10.0.26200
   • Microsoft Store package: OpenAI.Codex_26.707.9981.0_x64__2p2nqsd0c76g0
   • Package status: Ok
   • Host executable: ChatGPT.exe

   Reproduction evidence

   Before a controlled restart:

   • The same ChatGPT.exe process (PID 36388) accumulated 983 matching Application Error events.
   • Representative fields:
     • Exception: 0xc06d007f
     • Faulting module: unknown
     • Fault offset: 0x00007ff938771ada
   • In one five-minute interval, 11 new events were recorded (~2.1/min).
   • %LOCALAPPDATA%\CrashDumps rotated 10 dumps for that PID, totaling approximately 445 MB.
   • During a 10.7-second sample, two new events appeared and process write I/O increased by approximately 55 MB.
   • The main window still reported Responding=True, and normal thread/tool operations remained usable.

   After a normal exit and relaunch:

   • A new main PID (41284) and a new app-server PID were created.
   • The new PID reproduced the same 0xc06d007f event within seconds.
   • Within roughly ten minutes it produced 9 matching events and 9 new dumps totaling approximately 360 MB.
   • The new main process still remained alive and responsive.

   This rules out stale events from the previous process instance. A normal restart does not stop the dump generation.

   Local configuration checks

   • No ChatGPT.exe-specific LocalDumps registry key was present.
   • No SilentProcessExit\ChatGPT.exe configuration was present.
   • No postmortem debugger was configured for this executable.

   The operational problem is the repeated dump generation and associated disk I/O, even when the application remains usable. It should not generate hundreds of WER events and continuously rotate hundreds of megabytes of dumps during ordinary use.

   Issue #33381 reports the same exception on ARM64 and identifies a missing napi_create_function export involving node.napi.node. I have not symbolized the local x64 dumps, so I am not claiming that exact component as confirmed here, but the build number and exception signature match closely.

   Raw dumps and full application logs are intentionally not attached because they may contain local paths or private task data. I can provide a sanitized event export or a dump privately if requested.
5. nhmmnn commented on Jul 30, 2026

   

   nhmmnn

   on Jul 30, 2026 – with ChatGPT Codex Connector

   More actions

   I can reproduce a related form of system-wide mouse/UI stutter, but my measurements point to an additional graphics-surface/resource-lifecycle path involving DWM and repeated Codex in-app Browser workloads.

   Environment

   • Codex Desktop: 26.721.4979.0
   • OS: Windows 11 Pro N 25H2, build 26200.8894, x64
   • CPU: AMD Ryzen 9 7950X3D
   • RAM: 64 GB
   • GPU: AMD Radeon RX 7900 XTX
   • GPU driver: 32.0.31035.1003, dated 2026-07-24
   • Displays: Dual-monitor setup connected to the discrete GPU
   • Other agent application: Claude Desktop/Cowork was sometimes running concurrently
   • Primary workload: Long-lived Codex projects with repeated in-app Browser UI/UAT sessions

   Issue

   I am seeing recurring, sometimes severe, system-wide stuttering while Codex Desktop is active. The most visible symptom is a jerky mouse cursor. Initially, the stutter may affect only individual applications, but it can become system-wide.

   During severe episodes:

   • Mouse movement becomes visibly discontinuous.
   • Window animations and application interaction stall.
   • Other applications take abnormally long to start.
   • Even reaching or starting an application through Ctrl+Alt+Del can take a long time.
   • The condition can persist after the controlled in-app Browser tabs have already been closed.

   The problem became noticeable after performing many UI acceptance tests in the Codex in-app Browser. It is not triggered on every Browser action and sometimes appears with a delay of one to several 60-second monitoring intervals.

   Some recurrences happened during local checks when no new Browser tab, Browser action, or Browser subagent was started. This suggests that at least some of the resource growth may be delayed or retained from earlier Browser activity.

   Reproduction pattern

   The exact minimal reproduction is not yet isolated, but the recurring pattern is:

   1. Start or continue a long-lived Codex Desktop project.
   2. Perform repeated UI tests using the Codex in-app Browser.
   3. Open and close several controlled Browser tabs over the lifetime of the task.
   4. Finalize or close the Browser tabs.
   5. Continue local work or leave Codex idle.
   6. After some time, mouse and UI movement begin to stutter.
   7. Monitoring shows a sudden increase in the DWM working set and DWM-attributed shared GPU memory, despite low overall CPU and disk activity.

   Long-running tasks and accumulated node_repl processes appear to increase resource pressure, but node_repl accumulation is not required for the DWM increase: one captured DWM spike started while the node_repl count was zero.

   Instrumentation

   I created a persistent monitor that samples the following counters every 60 seconds:

   • DWM working set, private memory, CPU and GPU memory counters
   • System CPU, DPC and interrupt utilization
   • Available RAM, paging, disk queue and latency
   • Aggregate Codex, Claude, Chrome and Edge process memory
   • Number of Codex node_repl processes

   The monitor collected several thousand samples across multiple days.

   Performance evidence

   Representative captured values:

   State	DWM working set	DWM shared GPU	System CPU	Disk queue	Aggregate Codex WS	node_repl
   Healthy baseline	226.16 MB	59.14 MB	2.35%	0	2,231.74 MB	0
   Two minutes later	863.10 MB	669.14 MB	6.73%	0	2,413.43 MB	0
   High plateau	1,843.05 MB	1,639.26 MB	2.03%	0	3,963.93 MB	7
   Highest captured sample	2,065.73 MB	1,639.14 MB	8.10%	1	5,349.92 MB	8
   Immediately after controlled DWM restart	291.07 MB	63.14 MB	—	—	2,602.36 MB	9

   During the high plateau, approximately 32.5 GB of RAM was still available. At the highest captured sample, approximately 35.5 GB remained available. This does not resemble general CPU, RAM, or disk exhaustion.

   Single-minute increases

   One particularly clear transition occurred with the same DWM process ID:

   • DWM working set: 192.32 MB → 1,875.25 MB
   • DWM shared GPU: 21.14 MB → 1,639.14 MB
   • Aggregate Codex working set: 5,784.79 MB → 6,245.36 MB
   • node_repl: 7 → 11
   • System CPU after the increase: 4.73%
   • DPC utilization: 0%
   • Interrupt utilization: 0.05%
   • Disk queue: 0

   Another transition, also with the same DWM PID:

   • DWM working set: 294.03 MB → 870.39 MB
   • DWM shared GPU: 113.14 MB → 663.14 MB
   • System CPU: 3.16%
   • Disk queue: 0
   • node_repl: remained at 1

   Repeated captures show discrete shared-GPU increases rather than smooth growth. Observed plateaus were commonly around:

   • 59–125 MB during healthy operation
   • 500–700 MB during a medium-pressure state
   • Approximately 1,639 MB during the severe state

   The fixed-size nature of several jumps may be relevant to retained Chromium/DirectComposition surfaces or backing allocations, although that is only a hypothesis.

   Recovery evidence

   A controlled restart of dwm.exe produced an immediate recovery without restarting Codex:

   • Before: 847.2 MB DWM working set / 669.1 MB shared GPU
   • After: 291.1 MB DWM working set / 63.1 MB shared GPU

   The aggregate Codex working set stayed around 2.6 GB and nine node_repl processes remained alive. This makes a simple reduction in Codex process memory an unlikely explanation for the immediate recovery.

   The DWM restart was used only as a diagnostic. It is not an acceptable normal workaround.

   Closing all controlled in-app Browser tabs and explicitly finalizing the Browser session often returned DWM to approximately:

   • 139–208 MB working set
   • 73 MB shared GPU

   However, one delayed increase appeared during the third 60-second post-finalization sample. I therefore began requiring four consecutive clean samples before considering a Browser test block complete.

   Codex and node_repl process evidence

   The maximum observed daily node_repl counts were 15, 14, 12 and 13. On one day, aggregate Codex processes reached approximately 14.57 GB working set / 16.43 GB private memory.

   Closing or finalizing the Browser tabs does not always terminate the corresponding node_repl or MCP processes. Targeted cleanup reduces the count, but it can accumulate again during later work.

   This appears to be a related lifecycle/resource-retention problem, but not necessarily the direct cause of the DWM plateau. A DWM increase from approximately 226/59 MB to 863/669 MB occurred while node_repl remained at zero during the onset.

   Crash and event-log evidence

   Unlike the original report, I have not found matching Windows event records for:

   • Application Error event 1000 for Codex
   • Application Hang event 1002 for Codex
   • Display-driver reset event 4101

   The severe stutter usually occurs without a formal Codex or display-driver crash.

   Codex has separately shown UI/tool-transport errors. In one case, the model and reasoning controls disappeared and the app displayed an error. A targeted backend restart did not restore the connection, and the full Codex app had to be restarted. This may or may not share the same root cause.

   Troubleshooting performed

   • Multiple Windows restarts
   • Multiple Codex app restarts
   • Pausing Chrome during testing
   • Closing the Claude window
   • Restricting Codex to one controlled Browser tab at a time
   • Running Browser work serially with no Browser subagents
   • Explicitly closing and finalizing every Browser tab
   • Waiting for four clean 60-second samples after each Browser block
   • Targeted cleanup of stale node_repl processes
   • Disabling AMD overlay/DVR-related components
   • Disabling the unused integrated GPU
   • Running the official AMD Cleanup Utility
   • Performing a clean, driver-only AMD GPU driver installation
   • Controlled DWM restart as a diagnostic

   Closing Claude was not a perfect isolation test because some Claude/Cowork background processes were still present.

   After the clean AMD driver installation and reboot, the current DWM baseline is approximately 211–217 MB working set / 40 MB shared GPU. However, this has not yet been observed long enough under the original Browser workload to conclude that the driver reinstall permanently fixed the issue. Aggregate Codex memory and node_repl counts also remain elevated.

   Working hypothesis

   The measurements currently suggest two adjacent problems:

   1. A delayed or retained graphics-surface lifecycle problem. Repeated in-app Browser workloads appear to correlate with large, discrete increases in DWM-attributed shared GPU memory. The plateau persists at low system load and is released immediately by restarting DWM. Windows may attribute cross-process composition surfaces to DWM, so this does not necessarily mean that DWM itself owns or leaked the original allocation.

   2. Codex worker/process lifecycle accumulation. node_repl and other Codex child processes can remain alive after Browser tabs are finalized. This increases overall resource pressure and may raise the probability of the graphics problem, but it is not a necessary trigger in the captured data.

   A GPU-driver interaction remains possible. However, no display-driver reset was recorded, and the strong correlation with repeated Codex Browser usage means the Codex Chromium/DirectComposition lifecycle should also be investigated.

   Expected behavior

   • Closing or finalizing an in-app Browser tab should release its rendering surfaces and supporting processes.
   • Completed tasks and Browser sessions should not leave accumulating node_repl workers.
   • DWM working set and shared GPU attribution should return close to baseline.
   • Long-running Codex projects should not cause system-wide mouse or UI stutter.
   • Recovery should not require restarting DWM, Codex, or Windows.

   I can provide sanitized excerpts from the multi-day 60-second JSONL telemetry, exact before/after samples, process inventories, DWM recovery measurements, and the monitoring scripts. I am not attaching the raw logs publicly because they may contain local paths or private task data.
6. rayhaze commented on Aug 14, 2026

   

   rayhaze

   on Aug 14, 2026 – with ChatGPT Codex Connector

   More actions

   I am seeing the same severe system-wide input lag on the current Microsoft Store Codex Desktop build, 26.810.4967.0 x64.

   While Codex is running, mouse movement and keyboard input across Windows become noticeably delayed and the system is effectively unusable. This is not memory pressure: approximately 20 GB of RAM was free during the problem. Live sampling showed the Codex/ChatGPT UI and renderer processes consuming substantial CPU (the main UI briefly used nearly two logical CPU cores), matching the pattern in this issue.

   I found no matching ChatGPT.exe Application Error / Codex Micro crash events on this machine, so this appears to be the renderer/process-polling variant rather than the serialport crash path.

   This is a subscription-blocking regression for me. I will cancel my ChatGPT subscription unless it is acknowledged and fixed. Please provide a supported Windows mitigation that does not require fully closing Codex.