Windows Desktop: concurrent reasoning summaries correlate with ResizeObserver loops and UI freezes

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

• #33822
• #33524
• #33561

Powered by Codex Action

Reviewed the suggested potential duplicates:

• #33822 overlaps in the renderer symptom and ResizeObserver errors, but its controlled trigger is rendering an approximately 200 KB tool result.
• #33524 overlaps in the general post-merge Windows UI stalls, but its primary reproduction is thread resume/history navigation plus slow local service calls.
• #33561 overlaps in visible lag and older ResizeObserver errors, but focuses on repeated 0xc06d007f failures and a possible native-module delay-load path.

This report adds a different isolated A/B result on 26.715.4045.0: the ResizeObserver bursts correlate with reasoning-summary UI updates, and disabling concurrent_reasoning_summaries followed by a full process restart stopped the observed freezes and new matching errors so far.

I am therefore leaving this issue open as a narrower reproduction/root-cause lead, while acknowledging that these reports may share a renderer-level failure mode. I am happy to consolidate if maintainers confirm they have the same underlying cause.

Correction / updated diagnosis after further reproduction on OpenAI.Codex_26.715.4045.0_x64:

The concurrent_reasoning_summaries=false workaround was not durable. The desktop app later reproduced the same Windows Application Hang / Not Responding behavior. In addition, desktop logs show a remote Statsig feature override setting the feature back to true, despite the local config value.

More importantly, later hung processes had zero new ResizeObserver errors and zero reasoning-summary update bursts. The older process did contain 80 ResizeObserver errors correlated with 57 reasoning-summary updates, so that remains a real renderer symptom/possible trigger, but it is not sufficient to explain the recurring main-process hangs.

The newer evidence is a much closer match for #33884, #33780, and #33912: synchronous HID / Codex Micro device discovery blocking the Electron main thread.

Local hardware inventory on the affected PC found:

• Razer Huntsman V3 Pro (VID_1532&PID_02A6) connected through a Realtek USB hub, several USB topology levels below the root hub
• Razer Basilisk V3 Pro, Goliathus Chroma, and Kraken V4 Pro HID interfaces
• Corsair iCUE Commander Core (VID_1B1C&PID_0C32) and Elite Capellix LCD (VID_1B1C&PID_0C39)
• one present USB device in an error state: VID_0000&PID_0001, “port reset failed”

That inventory is notable because #33780 proves a Corsair composite HID can block HID.node -> hid.dll, while #33884 reports the periodic main-thread hang and successful A/B workarounds by bypassing Work Louder/Codex Micro discovery or moving/unplugging affected USB HID devices.

A plugin-disable A/B was also inconclusive: the app restored/reinstalled plugin state at startup, so it did not produce a clean isolation. Statsig refreshes sometimes took 10–32 seconds in logs, but current direct connectivity to the relevant endpoints is fast; this may amplify symptoms but is not proven as the root cause.

I am leaving this issue open for now, but the title/body should no longer be read as claiming ResizeObserver/concurrent summaries are the sole root cause. Maintainers: please consolidate this with #33884/#33780/#33912 if the HID trace explains this report as well.

Additional controlled A/B evidence from the same affected Windows installation (OpenAI.Codex_26.715.4045.0_x64):

I inspected the shipped app.asar and confirmed the current build still has this path:

• Codex Micro service reconnect delay: 1e4 (10,000 ms)
• connect() calls this.discovery.findWLDevices([DeviceType.Project2077])
• WLDeviceDiscovery.findWLDevices() synchronously calls nodeHID.devices()
• Work Louder filtering happens only after global HID enumeration

I then built a read-only out-of-process HID descriptor probe with a 2.5-second hard per-interface timeout. It enumerated 44 present HID interfaces and measured CreateFile, HidD_GetAttributes, manufacturer, product, and serial-string calls separately.

The main local trigger was a Razer Basilisk V3 Pro (VID_1532&PID_00AB) with 12 associated HID interfaces. Through the existing USB path—an active USB 2.0 extension plus a powered TP-Link UH720 V3 hub (internally two cascaded Realtek RTS5411 / VID_0BDA&PID_5411 4-port USB 2.0 hubs)—the 12 interfaces required 2,579 ms combined. Individual interfaces took up to 740 ms, with the delay specifically in HidD_GetManufacturerString, HidD_GetProductString, and HidD_GetSerialNumberString; open and attributes calls were only 0–2 ms.

Controlled change: move only the Basilisk directly to the PC's USB root hub.

Result with identical probe:

• before: 2,579 ms combined
• after: 110 ms combined
• improvement: 95.7%
• slowest interface after the move: 13 ms
• no descriptor timeouts

Finally, I quit the workaround-launched app and started Codex normally from the Start menu, so Codex Micro discovery was enabled again. A 55-second window-response probe spanning multiple discovery intervals recorded 91/91 responsive samples and zero hung episodes. Before isolating the USB path, a comparable 45-second run recorded 14 unresponsive samples out of 69.

Conclusion: a slow hub/extension/device path is a compatibility trigger, but the product defect is synchronous, unbounded all-HID enumeration on the Electron main thread. The robust app-side fix remains: use async/worker/utility-process discovery, prefilter the supported Work Louder VID/PIDs before descriptor reads, enforce hard timeouts/circuit breaking, back off instead of polling every 10 seconds, and expose a supported opt-out for optional Codex Micro discovery.

Confirmed working workaround, plus an important recovery detail for the system-wide choppiness variant.

On OpenAI.Codex 26.715.3651.0, heavy task updates could produce dense ResizeObserver activity and very fine sub-second choppiness. The effect spread beyond the Codex window: desktop animation and video playback also became choppy.

Preventing recurrence

In a backup-protected writable copy of resources/app.asar, I applied two exact same-length changes:

1. Replace:

``js
n?(0,Oe.flushSync)(I):I()
``

with n?setTimeout(I):I(), padded with ASCII spaces to the original length. This defers the ResizeObserver-triggered React commit instead of performing flushSync inside that path.

1. Replace the bundled reduced-motion resolver:

``js
function d({preference:e,systemPrefersReducedMotion:t}){switch(e){caseoff:return!1;caseon:return!0;casesystem:return t}}
``

with:

``js
function d({preference:e,systemPrefersReducedMotion:t}){return!0}
``

again padded with ASCII spaces to the original byte length.

I also launched Chromium with --force-prefers-reduced-motion. The AMD integrated display adapter was disabled so the RTX 4090 was the only active display adapter, followed by a Windows restart.

Already-degraded desktop requires a DWM restart

Completely closing every Codex / ChatGPT.exe process did not clear the system-wide choppiness. Once triggered, Desktop Window Manager remained degraded after Codex was gone. Win+Ctrl+Shift+B, disabling G-Sync, closing Docker/WSL, and disabling the translucent sidebar did not clear that state.

The recovery that immediately restored smoothness was:

1. Save work and close every Codex process.
2. Open PowerShell as Administrator.
3. Run:

``powershell
taskkill.exe /F /IM dwm.exe
``

Windows automatically starts a fresh dwm.exe; the displays briefly flash or blank. Signing out or rebooting is the fallback if DWM does not recover.

Result

After the DWM reset and final preventative configuration, the machine completed almost 24 hours of real heavy Codex use without recurrence. On this affected system, the combined workaround resolved all observed Codex freezes, fine-grained desktop/video choppiness, and persistent post-exit DWM degradation.

This is unsupported and the minified patterns are build-specific. It is a proven operational result on one machine, not a claim that every Windows stutter has the same cause. A product fix should remove synchronous flushSync work from the ResizeObserver/layout path and prevent renderer activity from leaving the compositor degraded after the app exits.

Follow-up from a current Windows release: this renderer path still reproduces on package OpenAI.Codex_26.721.4979.0_x64.

Config vs desktop override

The user-level config still contains:

[features]
concurrent_reasoning_summaries = false

However, the flushed desktop renderer log for this 4979 process recorded:

• 413 × Concurrent reasoning summaries feature override resolved featureOverride=true
• 0 × featureOverride=false

So the remote/desktop experiment is still overriding the local false value in this release.

Current log correlation

Across one 22.5-hour 4979 desktop log:

• 15,123 reasoning-related rows
• 512 ResizeObserver loop completed with undelivered notifications errors
• 127/512 ResizeObserver errors occurred within 500 ms after the most recent reasoning event
• 303/512 occurred within 1.5 seconds

The renderer also appears to process the same completion in multiple window contexts:

• 11,253 Reasoning summary item completed rows
• 3,855 unique reasoning item IDs
• 2.92 rows per unique item
• events were distributed across primary, avatarOverlay, and globalDictation renderer appearances

This is close to three-way duplicate delivery/bookkeeping, not merely a high number of unique reasoning items.

Live resource control

A separate 60.70-second read-only process sample on the same running 4979 instance found:

• root window responsive in 184/184 checks
• aggregate ChatGPT/Electron working-set peak: about 2,087.5 MiB
• packaged app-server: about 650.1 MiB working set / 1,152.4 MiB private memory
• three heavy renderer processes ended around 682.6, 480.1, and 349.4 MiB working set
• only one short-lived Git PID and two short-lived taskkill PIDs; no residual Git/taskkill processes

The user-visible symptom is increasing UI lag, especially during session switching, even though Windows continues to report Responding=True.

This does not prove that reasoning/ResizeObserver activity is the only Windows hang cause; the earlier HID diagnosis in this thread remains important. It does show that the reasoning-summary/ResizeObserver amplification itself is still active in 4979 and that the local disable is not authoritative.

Could maintainers please either honor the local disable in Desktop, disable this experiment on affected Windows builds, or deduplicate reasoning updates before broadcasting them to hidden overlay/dictation renderers?

Follow-up from a newer Windows desktop build: this renderer/layout-loop path still reproduces on OpenAI.Codex_26.721.11231.0_x64.

Environment

• Windows 11 Pro 25H2, build 26200.8875, x64
• Codex/ChatGPT Desktop package: 26.721.11231.0
• Chromium/file version: 150.0.7871.128
• NVIDIA GeForce RTX 5090 plus AMD integrated graphics
• Display scale factor: 1.75
• Microsoft Store/MSIX build

The user config contains a [features] section but no explicit concurrent_reasoning_summaries entry. The running desktop log recorded:

• 131 x Concurrent reasoning summaries feature override resolved featureOverride=true
• 0 x featureOverride=false

Current reproduction

Across the current desktop process lifetime:

• 1,747 x ResizeObserver loop completed with undelivered notifications
• 1,913 x Reasoning summary item completed
• reasoning completion delivery by renderer appearance:
• primary: 989
• avatarOverlay: 924

The visible UI remains severely choppy. This reproduced both while the RTX 5090 was nearly idle and later while a CUDA training process was saturating it, so GPU contention amplifies the symptom but does not explain the idle-GPU reproduction.

A read-only system sample also found:

• CPU queue: 0
• physical disk queue: 0
• average physical disk latency: about 0.068 ms
• physical disk throughput: about 0.58 MB/s
• low DPC/interrupt activity

This rules out physical disk I/O as the main cause in this reproduction.

Targeted renderer-reset A/B

To avoid interrupting long-running backend work, I identified the primary ChatGPT.exe --type=renderer process and terminated only that renderer. The desktop main process, packaged app-server, and external training process all remained alive. The app's renderer-crash recovery created a fresh renderer and reloaded the window.

Result:

• old primary renderer working set before reset: about 1,037 MB
• fresh renderer was created successfully
• React root render was requested at 23:52:13Z
• the first new ResizeObserver error appeared at 23:52:25.962Z, about 12.5 seconds later
• after active threads were restored, more than 20 matching errors occurred in roughly 0.3 seconds
• the user reported no perceptible responsiveness improvement

This shows that stale renderer accumulation is not required. Restoring active/streaming task state immediately re-triggers the layout feedback loop in a fresh renderer.

Working interpretation

This reproduction supports the reasoning-summary / multi-window delivery amplification described above: active task hydration and streaming updates appear to re-create the ResizeObserver loop, including delivery to the hidden avatarOverlay renderer. It does not prove that every Windows hang has this cause, but it is a directly reproducible frontend jank path in the current 26.721.11231.0 build.

Could maintainers please:

1. deduplicate reasoning-summary delivery to hidden auxiliary renderers;
2. avoid synchronous layout-affecting commits from ResizeObserver callbacks;
3. make the local disable authoritative for Desktop, or provide a supported runtime opt-out;
4. add a regression test that restores an active streaming task into a fresh renderer and asserts bounded observer delivery / frame latency?

No private prompts, thread IDs, local paths, or full logs are included here. Sanitized excerpts can be provided if needed.

Additional controlled A/B evidence from another Windows system on the current desktop build.

Environment

• Codex Desktop: 26.721.11231.0
• Chromium/file version: 150.0.7871.128
• GPU: Intel Arc A750, driver 32.0.101.8864
• Display: 3840×2160 at 120 Hz, Windows scaling 150% (device-scale-factor=1.5)

The user-visible symptom was severe frame stutter specifically while moving the pointer over the Codex UI or dragging the Codex window. Other desktop applications remained smooth. Updating the Intel graphics driver did not resolve it.

During a window-drag sample, Codex/ChatGPT showed substantial CPU-side renderer/compositor activity while GPU utilization remained relatively low. The current desktop log contained:

• 29 × ResizeObserver loop completed with undelivered notifications
• 18 × Reasoning summary item completed
• 4 × Concurrent reasoning summaries feature override resolved featureOverride=true

The user config already contained:

[features]
concurrent_reasoning_summaries = false

The bundled CLI recognized that value as false, but the running desktop renderer continued to log featureOverride=true.

Working A/B workaround

Adding this top-level setting to %USERPROFILE%\.codex\config.toml:

model_reasoning_summary = "none"

and then fully restarting Codex removed the observable window-drag/UI stutter in this environment. This setting suppresses creation of the reasoning-summary UI rather than relying on the overridden concurrent-summary feature flag.

This is an initial successful observation rather than proof that reasoning summaries are the only possible cause of Windows stutter. However, the clean behavioral change, the matching ResizeObserver/summary log activity, and the low GPU utilization provide another reproduction of the frontend layout-jank path on Intel graphics. I will follow up if the symptom returns during longer use.

Confirming this issue on another Windows system with a closely matching environment.

Environment:

• OpenAI Codex package: 26.727.6591.0
• Chromium/File version: 150.0.7871.182
• Windows 11 Pro 25H2, build 26200.8875
• NVIDIA GeForce RTX 4070 Ti

Observed behavior:

• Active Codex tasks eventually cause fine-grained, system-wide desktop and video stuttering.
• The degradation persists after minimizing Codex, closing extra chats, quitting iCloud Drive, and resetting the graphics driver with Win+Ctrl+Shift+B.
• Signing out of Windows temporarily restores normal desktop performance.
• Restarting Codex helps temporarily, but the problem returns after active tasks begin.

Diagnostics:

• Codex logs report Concurrent reasoning summaries feature override resolved featureOverride=true.
• Two logs from one affected day contained 219 occurrences of:

ResizeObserver loop completed with undelivered notifications.

• These errors appear around reasoning-summary item updates.
• During the degradation, DWM repeatedly measured approximately 133–156% in the Windows process performance counter, while multiple ChatGPT renderer processes were also active.
• Approximately 13–14 GB of RAM remained available and disk activity was low, so this did not appear to be memory or storage exhaustion.
• No recent display-driver errors were recorded.

I wonder what's going on that it affects DWM even after app is closed, like how?

Follow-up from the current Windows Desktop release: this renderer/layout-loop path is still active on OpenAI.Codex 26.818.3698.0 (UI release 26.818.31338, Chromium 151.0.7922.170) and has now progressed from jank/hangs to repeatable browser-main crashes.

Reproduction and crash timeline

On 2026-08-21 (UTC+8), normal multi-task use produced three full Desktop exits:

• 10:43:03
• 10:54:43
• 11:29:56

Each run created a Crashpad sidecar with:

{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}

Crashpad report identifiers:

• d548bcac-4627-41e7-a039-f5b75899d1f7
• 7fc16765-0072-40b9-b16e-7e56559dc840
• ac627570-75e6-441b-82f5-2ef9c533cdd0

Directly preceding renderer evidence

In the 10:54–11:29 process lifetime, the Desktop log contained:

• 1,165 log lines
• 196 error rows
• 152 × ResizeObserver loop completed with undelivered notifications
• 55 warning rows
• 11 worker RPC errors
• repeated Concurrent reasoning summaries feature override resolved featureOverride=true
• active reasoning-summary updates across multiple concurrent threads
• turn/started and turn/completed events for unknown conversations near the final minute
• a stale Git snapshot warning during a new turn

The app log ended about two seconds before the third Crashpad timestamp, with no normal shutdown sequence.

Fresh-process resource state

Only about three minutes after the automatic restart:

• browser-main: approximately 868 MB private memory, 1,917 handles
• GPU process: approximately 706 MB private memory, 7,321 handles
• total ChatGPT/Codex private memory: approximately 2.8 GB

The machine still had approximately 60 GB of physical memory free, so this was not global RAM exhaustion. Earlier the same day, Windows also recorded RADAR_PRE_LEAK_64 for ChatGPT.exe, and the Chromium GPU child process had crashed twice with exit code 34.

This is now a user-blocking regression: three browser-main crashes in under 47 minutes while several ordinary Codex tasks were streaming. Could maintainers please disable or deduplicate reasoning-summary delivery on affected Windows builds, make the local opt-out authoritative, or otherwise prevent the ResizeObserver/update storm from taking down the browser main process?

No private project data, account identifiers, thread IDs, or raw logs are included.

Additional Windows crash confirmation (26.818 release family)

Confirming repeated full Codex Desktop exits on Windows during active reasoning-summary streaming. This is now occurring multiple times per day and interrupts production work.

Environment

• Codex Desktop internal app release: 26.818.41509
• Installed MSIX release family: 26.818
• Chromium renderer: version 151
• Windows x64, build 10.0.26200
• 128 GB physical RAM; more than 100 GB remained available during the incident

Frequency

Distinct Desktop process sessions show:

• four restart transitions on 2026-08-23
• five restart transitions on 2026-08-24

Not every transition can be classified as a crash from logs alone. The latest incident was abnormal: the session log ended abruptly at 2026-08-24T23:40:57.272Z while an active worker was streaming reasoning-summary updates. There was no normal shutdown, update, quit, or relaunch sequence.

Directly preceding evidence

• 1,404 occurrences of ResizeObserver loop completed with undelivered notifications
• 98 occurrences of Git snapshot became stale
• 72 cancelled Git operations
• one 60-second Git timeout while scanning an unusually broad workspace
• active reasoning-summary updates at the final timestamp
• no logged fatal exception or out-of-memory condition
• no graceful-close marker
• no Windows Application Error/WER entry
• no locally retained Crashpad/minidump for this exit

The app used approximately 1.67 GB while the machine still had over 100 GB free. Global RAM exhaustion is therefore ruled out.

The broad workspace caused Git status/review scans over hundreds of paths. One command had argsCount=200, produced approximately 86 KB of output, and timed out after 60 seconds. This likely amplified renderer/update pressure, but it should not terminate the browser-main process.

User-visible impact

• Codex vanished during a long-running delegated coding task.
• The worker disappeared with the process.
• Partial filesystem edits survived, but the task had to be reconstructed and relaunched.
• The problem now occurs multiple times per day.

Working interpretation

This is consistent with the renderer/layout-update storm documented in this issue, amplified by concurrent reasoning summaries and large Git/task state. It does not prove the native root cause because this exit produced no retained dump.

Could maintainers verify whether this failure path can terminate the browser process before dump capture, and add bounded or paginated handling for reasoning-summary plus Git/review updates?

Privacy

This report intentionally excludes private prompts, repository names, account identifiers, thread IDs, usernames, local paths, and raw logs. Sanitized excerpts can be supplied if maintainers request them.