[Windows Desktop 26.820.9563.0] auto-resuming multi-GB tool-heavy threads triggers ResizeObserver storm and hard-freezes the OS

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

Microsoft Store/MSIX OpenAI.Codex 26.820.9563.0.

UI/Chromium file version: 151.0.7922.170.

What subscription do you have?

ChatGPT paid subscription (the exact tier is not relevant to this local desktop failure).

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

Additional environment details:

• Windows 11 Pro for Workstations 25H2, build 26200.9168
• Intel Core Ultra 9 275HX, 24 cores / 24 logical processors
• 192 GiB physical RAM
• NVIDIA GeForce RTX 5090 Laptop GPU, driver 32.0.16.1656
• Native Windows workspaces and local NVMe storage

What issue are you seeing?

Codex Desktop made the entire Windows desktop unusable while several long-running, tool-heavy tasks were active. The Codex icon disappeared, Task Manager could not be brought up, Explorer and unrelated apps stopped responding, and the machine had to be forcibly rebooted.

This is an unacceptable failure mode for a desktop client. A large conversation or failed renderer update may make the app slow, but it must not destabilize the shell/compositor badly enough that the user loses control of the OS.

The strongest local correlation is the combination of unbounded local rollout state, concurrent auto-resume/streaming, and a frontend layout-error storm:

• 93 local rollout JSONL files total 5.41 GiB.
• 14 rollout files exceed 100 MiB; 3 exceed 500 MiB.
• Three active threads were approximately 1.50 GiB, 828 MiB, and 193 MiB.
• Those three files contained approximately 26,619, 24,593, and 13,295 custom_tool_call_output records respectively.
• The three active rollouts continued to be appended after the forced reboot, confirming that active work was restored/resumed.
• The global local log database was approximately 332 MiB.

In the final 32-minute app-log window before the reboot, the desktop log contained:

• 780 total records
• 199 error records
• 183 occurrences of ResizeObserver loop completed with undelivered notifications
• peaks of 12 identical ResizeObserver errors in one second
• 64 thread_stream_view_activity_changed records as the UI moved among active threads
• repeated reasoning-summary delivery records
• multiple main_thread_jank_snapshot records, including one at 22:56 local time

The app log stopped abruptly at 23:02:10 local time. There is no normal shutdown sequence.

Correlated Windows timeline (UTC+8):

• 22:36:56 — Windows recorded Application Hang event 1002 for explorer.exe.
• 22:51:47 — Windows recorded Application Hang event 1002 for copyq.exe.
• 22:53–23:04 — Windows Error Reporting collected additional Explorer hang data.
• 23:02:10 — the Codex desktop log stopped abruptly while reasoning-related events were still arriving.
• 23:05 — the machine restarted after a forced power cycle; Windows recorded Kernel-Power event 41 (no clean shutdown).

After restart, while the client was hydrating/handling restored tasks, the bundled codex.exe app-server briefly used roughly 2.3–3.1 GiB resident memory and about 1.9 CPU cores in an 8-second sample. It later settled to roughly 1.0 GiB and near-idle CPU. This transient is consistent with expensive restoration of large active thread state, although it is not by itself proof of the pre-reboot peak.

No Codex OOM/fatal record, display-driver reset, or Windows Resource-Exhaustion-Detector event was retained during the final incident window. A Chromium GPU child process had crashed earlier that day, about 7.5 hours before the final incident, so it is evidence of renderer/GPU-process fragility but not a temporally direct cause. Corrected PCIe/WHEA warnings appeared only after reboot/device initialization. Because the whole system was forcibly restarted, no complete Codex crash dump or pre-reboot per-process memory sample survived.

No prompts, project names, thread IDs, account identifiers, private paths, raw conversations, or full logs are included. Sanitized excerpts can be provided through a maintainer-approved private channel.

What steps can reproduce the bug?

This reproduction can hard-freeze Windows, so it should be attempted only with watchdogs and resource limits:

1. On Windows Desktop 26.820.9563.0, keep multiple long-running tool-heavy threads active. In the affected state, three active rollouts ranged from about 0.2 to 1.5 GiB and each contained 13k–27k tool outputs.
2. Restart Codex so those active threads are restored, or switch among them while reasoning summaries and tool events continue streaming.
3. Monitor the desktop logs under %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs.
4. Observe repeated thread_stream_view_activity_changed, reasoning-summary events, main_thread_jank_snapshot, and bursts of ResizeObserver loop completed with undelivered notifications.
5. In the reported incident, UI responsiveness degraded beyond the Codex window: Explorer and clipboard UI hung, the Codex icon disappeared, Task Manager could not be opened, and a forced reboot was required.

What is the expected behavior?

• Thread hydration, attach, render, and resume must be paginated/windowed; no operation should deserialize or render an entire multi-GB rollout.
• Active conversations should be lazily resumed when focused, or restored with bounded concurrency and memory budgets.
• Tool outputs and reasoning-summary updates must be compacted/coalesced before delivery to the renderer and hidden auxiliary windows.
• The renderer must virtualize long transcripts and must not perform synchronous layout-affecting commits from a ResizeObserver callback.
• Repeated observer errors or main-thread jank must trigger a circuit breaker that pauses background hydration/streaming instead of continuing the update storm.
• After an unclean shutdown, Codex should offer a safe-start mode that does not auto-resume all previously active tasks.
• Per-thread/local-history size limits and a supported compact/archive workflow should be exposed before data reaches multi-GB scale.
• Under no circumstance should a Codex workload make Task Manager, Explorer, or the Windows desktop unavailable.

Additional information

Related issues cover important parts of the same failure family:

• #40934 — unbounded memory growth and aggressive auto-resume of long-running threads
• #33996 — reasoning-summary delivery, ResizeObserver loops, and Windows UI freezes
• #25779 — meta-bug for unbounded session/turn state
• #33368 — long-running sessions causing whole-PC lag/freezes

This report adds a current 26.820.9563.0 forced-reboot reproduction, exact on-disk rollout scale and tool-output counts, a quantified ResizeObserver/error window, and the correlated Windows shell-hang timeline. The evidence supports a client-side state-management/rendering failure amplified by very large active threads. It does not support blaming the selected language model itself: model inference is remote, while the recorded failure path is in local restoration, event delivery, and desktop rendering.

Start by reviewing the Codex logs under %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs and the related issues #40934, #33996, #25779, and #33368. Trace the reported thread_stream_view_activity_changed, main_thread_jank_snapshot, and ResizeObserver error activity; done should prevent unbounded restoration/rendering from producing update storms or freezing the Windows desktop.