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

Summary

On Codex/ChatGPT Desktop for Windows, the UI repeatedly became sluggish or temporarily unresponsive. The desktop log showed bursts of ResizeObserver loop completed with undelivered notifications errors. These bursts correlated almost exactly with concurrent reasoning-summary items being added or completed in the renderer.

Disabling concurrent_reasoning_summaries in the Codex config and fully restarting all ChatGPT/Codex processes stopped the visible freezing in this environment. No new ResizeObserver errors or Windows application hangs have been recorded since the targeted restart so far.

Related general Windows performance report: #20214.

Environment

Codex/ChatGPT Desktop package: OpenAI.Codex_26.715.4045.0_x64
Chromium/file version: 150.0.7871.124
Windows 11 Pro 25H2, build 26200.8875, x64
GPU: NVIDIA GeForce RTX 4090 plus AMD integrated graphics
Two displays, 150% (device-scale-factor=1.5)
Installed from the Microsoft Store/MSIX package

Observed behavior

UI pauses and occasional Windows Not Responding state
Delayed interaction while reasoning/status content updates
55 occurrences of the following renderer error in one approximately 13-minute app session:

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

Windows Event Viewer recorded three Application Hang events for ChatGPT.exe version 150.0.7871.124 during the affected period.
An earlier app version (26.707.8479.0) also produced ChatGPT.exe crashes with exception code 0xc06d007f, although those older crashes may be a separate failure mode.

Correlation

The ResizeObserver errors repeatedly appeared immediately before or after log entries such as:

Reasoning summary item completed ... summaryPartCount=...
Reasoning summary part added ...

The app also logged:

Concurrent reasoning summaries feature override resolved featureOverride=true

Workaround

Add the following to %USERPROFILE%\.codex\config.toml:

[features]
concurrent_reasoning_summaries = false

Then fully terminate all ChatGPT.exe, codex.exe, and related Codex background processes before restarting the desktop app. Merely closing and reopening the window can leave the original renderer/background processes active.

The bundled Codex CLI confirms:

concurrent_reasoning_summaries    under development    false

After the full restart, the user reports that the freezing appears resolved. The post-restart observation currently shows zero new ResizeObserver errors and zero new Windows application hangs.

Expected behavior

Updating or completing reasoning-summary UI items should not trigger ResizeObserver loops or make the renderer unresponsive. If the experiment causes a layout feedback loop on Windows, it should be disabled for affected builds or the relevant resize callback should avoid synchronously changing observed dimensions.

Notes

A clean profile and reinstall had not resolved the original freezing.
The issue occurred before old conversations were restored, so restored history was not the initiating cause.
GPU-disabled testing did not resolve the broader freezing, so hardware acceleration does not appear to be the sole cause in this environment.

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

Windows Codex Desktop 26.715.2305.0 hangs while rendering ~200 KB tool output #33822
[Windows][Desktop 26.707.9981.0] Post-merge thread switching and prompt submission freeze with thread/resume latency and ResizeObserver errors #33524
[Windows Desktop 26.707.12708.0] Severe lag while typing and switching tasks; repeated 0xc06d007f crashes #33561

Powered by Codex Action

Reviewed the suggested potential duplicates:

Windows Codex Desktop 26.715.2305.0 hangs while rendering ~200 KB tool output #33822 overlaps in the renderer symptom and ResizeObserver errors, but its controlled trigger is rendering an approximately 200 KB tool result.
[Windows][Desktop 26.707.9981.0] Post-merge thread switching and prompt submission freeze with thread/resume latency and ResizeObserver errors #33524 overlaps in the general post-merge Windows UI stalls, but its primary reproduction is thread resume/history navigation plus slow local service calls.
[Windows Desktop 26.707.12708.0] Severe lag while typing and switching tasks; repeated 0xc06d007f crashes #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:

Replace:
```
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.

Replace the bundled reduced-motion resolver:

function d({preference:e,systemPrefersReducedMotion:t}){switch(e){case`off`:return!1;case`on`:return!0;case`system`:return t}}

with:

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:

Save work and close every Codex process.
Open PowerShell as Administrator.
Run:
```
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:

deduplicate reasoning-summary delivery to hidden auxiliary renderers;
avoid synchronous layout-affecting commits from ResizeObserver callbacks;
make the local disable authoritative for Desktop, or provide a supported runtime opt-out;
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.

Newer-build evidence and a reproducible summary opt-out precedence gap

Adding sanitized findings from a September 4, 2026 Windows incident and a read-only inspection on September 5. The PC gradually slowed until a forced shutdown was necessary. This resembles reports here and in #33368 / #41166, but the retained evidence does not establish a shared root cause, a RAM/VRAM leak, or that reasoning summaries caused the whole-PC freeze.

Separately, the installed desktop bundle has a reproducible precedence behavior: an experiment-driven detailed summary overrides inherited and next-turn none values. An explicit per-request none still wins. This is a concrete opt-out fix candidate, not a verified freeze fix.

Environment and retained incident evidence

Windows 11 Pro, build family 26200, x64; approximately 64 GiB RAM; NVIDIA RTX 5090 with approximately 32 GiB VRAM.
Incident package identified in its process log: 26.901.4073.0. Package inspected after restart: 26.901.5280.0.
ChatGPT Desktop, Chrome, and LTX Desktop were open. Times below are September 4, UTC−06:00.
456 ResizeObserver loop completed with undelivered notifications errors across the day, first at 08:52:46 and last at 15:22:52. These were not all in the final minutes.
25 main_thread_jank_snapshot records, including repeated records at 15:57–16:03; browser-sidebar color-scheme synchronization timed out at 16:05:06.
LTX backend health checks failed at 15:55 and 16:03; other Windows components also timed out, supporting system-wide loss of responsiveness.
Windows recorded an unexpected shutdown around 16:05, a power-button timestamp of 16:06:41, and subsequent Kernel-Power 41 with BugcheckCode=0.
No incident-window Event 2004, WHEA hardware error, or NVIDIA/display reset was found in the inspected retained logs. Absence of these events does not rule out resource exhaustion or driver involvement.
LTX generation had finished at 14:40:56. Its completion sample showed 0.01 GiB GPU memory allocated, 1.98 GiB reserved, and 28.16 GiB free, after a 23.16 GiB peak.

No complete pre-freeze per-process resource history was available, and protected LiveKernelReports could not be inspected. The layout errors and later stalls do not establish an immediate causal chain. An initial desktop-log read returned empty content; a later read returned the retained records above, for an unknown reason.

Reproducible behavior in the newer desktop bundle

Asset: webview/assets/app-initial-ffce11d82782.js in package 26.901.5280.0.

SHA-256: 30bfcbdbc47b90bc72fa8853e949dce2eee6b519d3876113260c939801f17203.

The desktop constructs reasoningSummaryOverride: "detailed" when getDefaultFeatureOverride("concurrent_reasoning_summaries") returns true. The inspected turn-start resolver then applies:

Inherited summary, falling back to none.
Next-turn summary, if provided.
Experiment summary override, if present.
Explicit request summary, if provided.

Thus steps 1 and 2 can supply none and still produce detailed. The same bundle also has a voice-start path that calls updateThreadSettingsForNextTurn with summary: "detailed" when the experiment is enabled.

The reproduction below reads the exact installed asset, checks that the reviewed expression occurs once, and executes only that small expression with synthetic inputs. It passed seven assertions: three observed-precedence cases and four proposed-policy cases. It does not modify the app, launch Codex, or make model calls.

Scope: this is a function-level reproduction, not an end-to-end demonstration that a particular config-file edit is ignored or that disabling summaries prevents the Windows freeze.

Proposed maintainer change and validation

Preserve the provenance of an explicit user/project/task summary opt-out. Let the experiment supply a default only when no explicit opt-out applies, while retaining precedence for an explicit per-request choice. Apply that rule consistently to task creation, next-turn resolution, task restoration, and voice startup.

Suggested regression checks:

With the experiment enabled and an explicit user/project model_reasoning_summary = "none", verify that the outgoing turn remains none.
Verify that an explicit task opt-out survives restoration, the next turn, and voice startup.
Verify unchanged defaults when no explicit preference exists, and that an explicit request choice still wins.
Before claiming a freeze fix, repeat the affected Windows workload with bounded resource recording and compare stalls, layout errors, process counts, CPU, private bytes, and handles.

The proposed helper in the reproduction is a policy illustration, not a drop-in production patch: the real code must retain explicit-setting provenance. The relevant override was found in the shipped desktop frontend; no public source patch target for that path was found. No application/configuration changes or before/after freeze fix have been deployed on this machine.

Read-only Node.js reproduction (no external packages)

Save as codex-summary-opt-out-repro.cjs and run node codex-summary-opt-out-repro.cjs, or pass an absolute app.asar path as the first argument. It intentionally stops if the reviewed build/expression differs.

// Read-only, function-level reproduction. Does not run Codex or call a model.
// Usage: node codex-summary-opt-out-repro.cjs [absolute-path-to-app.asar]
const fs = require('node:fs');
const vm = require('node:vm');
const assert = require('node:assert/strict');
const crypto = require('node:crypto');

const asarPath = process.argv[2] || 'C:/Program Files/WindowsApps/OpenAI.Codex_26.901.5280.0_x64__2p2nqsd0c76g0/app/resources/app.asar';
const assetPath = 'webview/assets/app-initial-ffce11d82782.js';
const observedExpression = 'Te=L?.summary??`none`;E?.summary!==void 0&&(Te=E.summary),o.reasoningSummaryOverride!=null&&(Te=o.reasoningSummaryOverride),s.summary!==void 0&&(Te=s.summary);';

function readAsset() {
  const fd = fs.openSync(asarPath, 'r');
  try {
    const header = Buffer.alloc(16);
    assert.equal(fs.readSync(fd, header, 0, 16, 0), 16);
    const headerLength = header.readUInt32LE(12);
    assert.ok(headerLength > 0 && headerLength < 16 * 1024 * 1024);
    const dataOffset = 8 + header.readUInt32LE(4);
    const data = Buffer.alloc(headerLength);
    assert.equal(fs.readSync(fd, data, 0, data.length, 16), data.length);
    let entry = JSON.parse(data.toString('utf8'));
    for (const part of assetPath.split('/')) entry = entry.files[part];
    assert.ok(!entry.unpacked && entry.size < 25 * 1024 * 1024);
    const contents = Buffer.alloc(entry.size);
    assert.equal(fs.readSync(fd, contents, 0, contents.length, dataOffset + Number(entry.offset)), contents.length);
    return contents;
  } finally {
    fs.closeSync(fd);
  }
}

const asset = readAsset();
const source = asset.toString('utf8');
assert.equal(source.split(observedExpression).length - 1, 1, 'Expected exactly one reviewed expression; stop if this app build differs.');
const resolveObserved = (values) => vm.runInNewContext(`let ${observedExpression} Te`, values, { timeout: 100 });

// Proposed policy, not a drop-in patch: production code must obtain an
// explicit opt-out from the resolved user/project or task setting and retain
// that provenance instead of treating an inferred default as a user choice.
function resolveCandidate({ requestSummary, explicitOptOut, experimentSummary, inheritedSummary }) {
  if (requestSummary !== undefined) return requestSummary;
  if (explicitOptOut) return 'none';
  return experimentSummary ?? inheritedSummary ?? 'none';
}

const base = { L: { summary: 'none' }, E: undefined, o: { reasoningSummaryOverride: 'detailed' }, s: {} };
assert.equal(resolveObserved(base), 'detailed');
assert.equal(resolveObserved({ ...base, E: { summary: 'none' } }), 'detailed');
assert.equal(resolveObserved({ ...base, s: { summary: 'none' } }), 'none');
assert.equal(resolveCandidate({ explicitOptOut: true, experimentSummary: 'detailed' }), 'none');
assert.equal(resolveCandidate({ explicitOptOut: false, experimentSummary: 'detailed' }), 'detailed');
assert.equal(resolveCandidate({ explicitOptOut: true, experimentSummary: 'detailed', requestSummary: 'detailed' }), 'detailed');
assert.equal(resolveCandidate({ explicitOptOut: false, inheritedSummary: 'concise' }), 'concise');

console.log(JSON.stringify({
  scope: 'Function-level summary-precedence check; not an end-to-end freeze reproduction',
  packageVersion: '26.901.5280.0',
  asset: assetPath,
  assetSha256: crypto.createHash('sha256').update(asset).digest('hex'),
  observed: 'Inherited and next-turn none values become detailed when the experiment override is detailed; an explicit request none wins.',
  candidate: 'Explicit opt-out wins over the experiment default; an explicit request can still override it.',
  assertionsPassed: 7,
  appModified: false,
  modelCalls: 0
}, null, 2));

This comment excludes account identifiers, private project paths, conversation text, prompts, credentials, raw databases, and full logs.

Additional browser-process crash evidence from the current Windows build

I can confirm three intermittent full Codex Desktop exits during ordinary multi-task use on the current Microsoft Store/MSIX release.

Environment

OpenAI Codex Desktop: 26.908.4834.0 (x64)
Chromium/file version: 152.0.7977.83
Windows 11 Pro 25H2, build 26200.9445, x64
Microsoft Store/MSIX installation

Crashpad evidence

Three sidecars were created in approximately 37 hours:

2026-09-12 02:22:32 +01:00 — 98159218-bae4-499b-84ff-e1b3dc590d20
2026-09-12 20:18:22 +01:00 — 943d7b64-8f61-4605-9bad-64f2b1bc2f88
2026-09-13 15:26:19 +01:00 — 6eb64912-c9e0-4bcc-9b02-b3be9cac26b5

Every sidecar contains the same classification:

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

Latest crash correlation

For the latest crashed process, the two rotated main logs accumulated 2,145 ResizeObserver loop completed with undelivered notifications errors and 4,308 reasoning-summary update/completion rows. The last log ends at 2026-09-13T14:26:18.571Z, and the browser-process Crashpad sidecar was created about 0.6 seconds later.

Immediately before the exit, the renderer emitted a dense burst of ResizeObserver errors from 14:25:52Z through 14:26:17Z, roughly once per second. There is no normal shutdown, quit, or relaunch marker in that process log. The replacement process started at 15:02:45Z and had already recorded 174 additional matching ResizeObserver errors by 16:16:48Z.

Windows Event Viewer did not retain a matching Application Error or Application Hang event for these exits, and only the Crashpad sidecars are present locally, not full dump files. Therefore this evidence confirms browser-process crashes but does not establish the native exception or prove that ResizeObserver/reasoning-summary activity is the sole root cause.

User impact

The whole desktop application disappears intermittently while tasks are active, interrupting ongoing work and requiring the application and task state to recover after restart.

Could maintainers investigate the browser-process termination around these renderer-update storms and ensure that a usable crash dump is retained or uploaded for this failure path? No private prompts, task identifiers, repository names, account data, local paths, or raw logs are included here.

Windows 26.908: slow switching between small paginated tasks with fast history RPCs

Adding a current-build observation that may help separate history retrieval from renderer work.

Environment: Microsoft Store/MSIX OpenAI.Codex_26.908.4834.0_x64, frontend bundle 26.908.40834, Chromium 152.0.7977.83.

The user reports noticeably slow switching back and forth between two local tasks whose rollout files are approximately 6.8 MB and 9.1 MB. Both use paginated history. A separate approximately 899 MB task remains active elsewhere in the same application, so this is not a controlled test excluding large background state. However, selecting the huge task is not required for the reported switching symptom.

A bounded 4 MiB excerpt of the same app session's main-process log, covering 2026-09-14T01:20:55Z through 02:17:25Z, contains:

188 ResizeObserver loop completed with undelivered notifications. errors across two renderer windows (106 and 82).
Active-view events let us associate 43 errors with the approximately 9 MB task and 43 with the large task; the remaining 102 are unassigned/other. These are not counts for each of the two small tasks. There is insufficient retained activity evidence to assign errors to the approximately 7 MB task.
Four recorded activations of the 9 MB/large tasks each had 1–2 matching errors in the following ten seconds. The highest minute contained 48 errors.
thread/read responses took at most 8 ms for the 9 MB and large tasks; thread/turns/list took at most 18 ms and 47 ms, respectively. Observed queue wait was at most 1 ms.
For the 9 MB task, thread/resume took 185 ms, and the logged maybe_resume_started → maybe_resume_success interval was about 522 ms. No equivalent successful-resume interval was established for the large task.
Three Concurrent reasoning summaries feature override resolved featureOverride=true records were present.

Read-only inspection of this installed frontend found turn virtualization with overscan 2. The raw rollout sizes therefore must not be interpreted as all-history DOM size. There is still entry/item processing before the visible-turn slice, item processing inside a large single turn, and proximity-triggered history hydration that need not wait for user scrolling. Those are investigation candidates, not a reproduced root cause.

Scope/limitations: the slow two-small-task switching is user-observed, while the timing/error counts above come from the earlier bounded log interval. At the time of this initial log-only observation, no controlled foreground performance trace or same-switch ResizeObserver stack had been captured; see the subsequent trace update below. The evidence supports a common renderer/layout-path investigation but does not prove ResizeObserver causes the delay rather than accompanying it. Background large-task processing is still a confounder. No summary opt-out, zoom, cache, app bundle, task state, or window configuration was changed for this report, and no crash/OOM claim is made.

Could maintainers correlate task-entry JavaScript/layout/paint time with the component generating these ResizeObserver events, and check whether currently projected item processing or automatic hydration delays first usable paint? It would also help to know which summary opt-out is actually authoritative in this build, given the conflicting workaround/override reports already in this issue.

The broader task-switching report #30428 may also be relevant, but its different tracing evidence should not be assumed to establish the same cause. This comment includes no task identifiers, business content, account data, private filesystem paths, raw rollouts, or full logs.

Follow-up: a short local trace points to subagent membership state work, not dominant ResizeObserver delivery time

A new, shorter performance trace was retained locally. The user navigated from a large task to another task, then stopped recording. Returning afterward felt fast, but that return was outside the trace, so this is not a measured bidirectional comparison and does not establish a cache effect.

The captured renderer main thread contains one complete EventDispatch(type=click) taking 29.672 s wall time / 28.207 s thread CPU time (95.06%). Almost the entire interval contains the same React microtask callback in client-d8dffccad60c.js (1-based line 8, column 122951). CPU stacks now retain their initial Profile and referenced node definitions, unlike an earlier longer recording that overwrote its ring buffer.

The actionable path is:

React passive effects → subscription mount → atom evaluation/read/family resolution → subagent membership derivation.

In this build, the profile label Jf.isEqual at app-primary-17b54400f32a.js (0-based line 1167, column 32779) maps to the body of the w7 derived atom, which builds subagent membership and reads related state. It is not evidence that a deep-equality comparator itself takes 25 seconds. That subtree has approximately 25.671 s inclusive sampled time in the approximately 35.067 s renderer profile. Its related qdr membership assembly and Xdr candidate traversal account for approximately 3.064 s and 1.431 s inclusive sampled time, respectively; these overlap and must not be added. Larger costs appear in atom reads and family resolution under the derived computation. These are whole-profile sample weights, not exact per-function CPU timings or invocation counts.

For comparison, retained events on the same renderer main thread contain:

LocalFrameView::NotifyResizeObservers: 18.993 ms total, 157 calls, maximum 4.577 ms.
Layout: 82.063 ms total, 50 calls.
UpdateLayoutTree: 463.783 ms total.
Paint: 49.425 ms total.

There is one browser console notification containing the ResizeObserver error, about 0.476 s after the long click completes, plus two duplicate log-layer records. Browser receipt timing and renderer attribution are not sufficient to rule out an indirect trigger. Nevertheless, direct ResizeObserver/layout delivery costs do not account for the captured 29.7-second main-thread stall. This narrows the previous renderer/layout hypothesis toward state derivation and subscription work; this task-switching stall may deserve separate treatment from other ResizeObserver reports in this issue.

Suggested investigation/fix scope: measure membership-selector reevaluation counts, input cardinalities, and subscription mount/invalidation triggers; determine whether unchanged relationship results and per-thread reads can be reused, and whether dependencies can be scoped to the visible parent/turn instead of repeatedly traversing broader cached conversation/history state. A targeted regression should exercise task switching with a large retained task/subagent graph. The current trace does not establish input counts, algorithmic complexity, a memory leak, or that any particular configuration change fixes this.

Trace quality: buffer overwrite counts are zero and all referenced CPU nodes were found. The trace processor still reports 540 track parser errors/missing hierarchy entries and 99 discarded chunks, so this is not a claim that every track is lossless. The reported long event is complete and its CPU stack references resolve. Profiling overhead remains a limitation. The exact destination task is based on the user's action description, not independently established from the event payload.

The trace, task identifiers, raw logs, private paths, and business content remain local. Only these aggregate measurements and installed-build code locations are shared. No app bundle, configuration, history, or window setup was modified. A verified desktop-source change/build is still required before any fix can be claimed.

Version-specific local patch/startup confirmation with Codex assistance:

Windows 10 Pro x64, 10.0.19045 (local OS probe).
Desktop package 26.1007.2314.0, internal app 26.1007.21434; bundled backend 0.162.0-alpha.17.2.
In webview/assets/virtualized-turn-list-93f4162a687b.js, the single matching expression was n?(0,Te.flushSync)(se):se(). It was replaced with n?setTimeout(se):se() and padded to preserve the original byte length.

The change was made in a backup-protected writable portable copy. The corresponding ASAR asset/header and embedded integrity digest were updated while integrity fuses remained enabled. The original Store installation is untouched. The modified portable executable loses its vendor signature; this is an unsupported, build-specific workaround.

JavaScript syntax and seven callback-behavior assertions passed. A cold launch through the verified Desktop shortcut observed the patched executable and responsive process samples. Historical logs had 3,563 ResizeObserver errors, but I have not measured sustained post-patch UI frame time or a comparable long-session error-rate reduction, so this is patch/startup confirmation rather than proof that all UI freezes are resolved.

I separately reproduced local MCP transport pressure; that evidence belongs in #42740. Successful remote compaction and long-running UI responsiveness remain unverified.

Sanitized report and verification limits: https://gist.github.com/CrispyW0nton/ec298528829397c5389dd49fba193578

macOS renderer trace findings on 26.1007.30912 (unpatched app)

Adding a cross-platform observation to this renderer discussion. These measurements do not establish the same underlying cause as the Windows reports above.

Environment and method

macOS on Apple Silicon; desktop app 26.1007.30912, build 20156; bundled backend 0.162.0-alpha.17.2.
Reduce motion was On. The app bundle was left unchanged.
Used Help → Start Performance Trace, switched chats while investigating sluggishness, then stopped recording and cancelled upload. Analysis was local with Perfetto v58.2.
The app reported 38.126 seconds of recording and bufferFull=false; parsed monotonic trace bounds span 51.555 seconds. Counts below cover the parsed trace, without normalising rates to the app-reported duration.

Renderer measurements

After excluding main-thread tasks containing CpuProfiler::StartProfiling, one renderer's CrRendererMain had 13 complete tasks over 50 ms, including 8 over 100 ms. The maximum was 353.910 ms wall time.

Task	Observed nested work
353.910 ms message-port/microtask task	React scheduler callback: 206.692 ms; synchronous style/layout: 38.086 ms; minor GC inside that callback: 23.675 ms
349.830 ms mouse-release input task	React scheduler microtask callback: 315.271 ms; synchronous style/layout inside it: 31.182 ms

These are nested wall durations and must not be added together. The React callbacks resolve to app-shared-8bd9d0399038.js, trace-reported line 90, column 123793.

Samples also contain querySelectorAll, querySelector, atom-state dependency work and scroll/viewport geometry reads. Read-only inspection of the installed assets matched these profile locations (zero-based line and column):

Eit: app-shared-8bd9d0399038.js, 293:48361, dependency traversal.
Dit: the same asset, 293:48935, atom-state reads/recomputation.
kGt: the same asset, 422:15323, reads scrollHeight, clientHeight and scrollTop.
reconcileViewport: thread-response-space-controller-d9944902d856.js, 0:5899.

These locations identify sampled activity; attribution to a particular application component or selector remains unresolved. The largest major-GC event was 191.236 ms.

Keep profiler startup separate

The largest multi-second task envelopes contained profiler startup: CpuProfiler::StartProfiling took 6,938.993 ms in one renderer and 2,307.290 ms in another. Those tasks are excluded from the counts above.

Backend and ResizeObserver observations

During the app-reported recording window, maximum logged RPC durations were:

thread/read: 157 ms (38 requests).
thread/turns/list: 1,220 ms (44 requests).
thread/items/list: 650 ms (76 requests).

One ResizeObserver warning was logged in that window. A causal ResizeObserver/flushSync feedback loop was not established, and no renderer workaround was applied or validated.

Profiling perturbs timing. Perfetto reported legacy_v8_cpu_profile_invalid_callsite=1 and legacy_v8_cpu_profile_invalid_sample=1, limiting CPU-stack completeness. The figures describe this recorded session, rather than an uninstrumented baseline or a demonstrated fix.

A useful investigation would correlate subscription/atom reevaluation, synchronous geometry reads and layout work with chat-switch input tasks, while separating history-fetch latency and profiler startup costs.

Only aggregate measurements and shipped-code locations are shared here. No raw trace, full logs, conversation content, task/account identifiers or private filesystem paths are attached or included.

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

Description

Summary

Environment

Observed behavior

Correlation

Workaround

Expected behavior

Notes

Activity

github-actions commented on Jul 18, 2026

michaelstienstra25-sudo commented on Jul 18, 2026

michaelstienstra25-sudo commented on Jul 19, 2026

michaelstienstra25-sudo commented on Jul 19, 2026

mm0nst3r commented on Jul 19, 2026

Preventing recurrence

Already-degraded desktop requires a DWM restart

Result

areslp commented on Jul 26, 2026

Config vs desktop override

Current log correlation

Live resource control

kongtou20070406 commented on Jul 31, 2026

Environment

Current reproduction

Targeted renderer-reset A/B

Working interpretation

duron9000 commented on Jul 31, 2026

Environment

Working A/B workaround

lucasimo commented on Aug 4, 2026

Kadeluxe commented on Aug 16, 2026

stillflood commented on Aug 21, 2026

Reproduction and crash timeline

Directly preceding renderer evidence

Fresh-process resource state

rickgude commented on Aug 25, 2026

Additional Windows crash confirmation (26.818 release family)

Environment

Frequency

Directly preceding evidence

User-visible impact

Working interpretation

Privacy

avezey-ci commented on Sep 5, 2026

Newer-build evidence and a reproducible summary opt-out precedence gap

Environment and retained incident evidence

Reproducible behavior in the newer desktop bundle

Proposed maintainer change and validation

igscomp commented on Sep 13, 2026

Additional browser-process crash evidence from the current Windows build

luvs01 commented on Sep 14, 2026

Windows 26.908: slow switching between small paginated tasks with fast history RPCs

Follow-up: a short local trace points to subagent membership state work, not dominant ResizeObserver delivery time

CrispyW0nton commented on Oct 12, 2026

NellInc commented on Oct 13, 2026

macOS renderer trace findings on 26.1007.30912 (unpatched app)

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions