›_ Codex Issues
Codex Issues / #33042

VS Code extension 26.707: streaming warning loop repeatedly crashes renderer with SIGILL on Linux

Open 💬 3 comments Opened Jul 14, 2026 by prasannavl
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Description

The Codex VS Code extension repeatedly crashes its webview renderer on Linux/Wayland while a response is streaming. Immediately before each crash, the extension log floods with unhandled thread-stream-state-changed broadcasts interleaved with ResizeObserver errors. The renderer then terminates with SIGILL at the same relative instruction offset on every occurrence.

The Codex app-server process remains alive after the crash, as do the VS Code main/workbench and GPU processes. There is no OOM event. This appears to be a Codex webview/frontend failure rather than a backend or whole-editor crash.

I reproduced this three times with the same native signature:

| Time (local) | Signal | Relative instruction offset |
| --- | --- | --- |
| 2026-07-12 17:50:18 | SIGILL / invalid opcode | 0x3ac5667 |
| 2026-07-14 13:42:08 | SIGILL / invalid opcode | 0x3ac5667 |
| 2026-07-14 16:36:46 | SIGILL / invalid opcode | 0x3ac5667 |

Steps to reproduce

This is intermittent, but the observed pattern is:

  1. Open the Codex panel in VS Code and resume an existing conversation.
  2. Start a stream-heavy turn that produces multiple incremental reasoning/tool events.
  3. Leave the Codex panel active while the response streams.
  4. The extension log begins emitting repeated thread-stream-state-changed and ResizeObserver errors.
  5. The Codex UI disappears/crashes while the app-server process continues running.

Two VS Code windows were open during the latest occurrence, and both extension logs received the stream-state broadcasts. I have not yet established whether multiple windows are required.

Expected behavior

Streaming updates should be handled without a log loop or renderer crash.

Actual behavior

The following sequence repeats immediately before the native crash:

Received broadcast but no handler is configured method=thread-stream-state-changed
[desktop-notifications][global-error] ResizeObserver loop completed with undelivered notifications.
Received broadcast but no handler is configured method=thread-stream-state-changed
[desktop-notifications][global-error] ResizeObserver loop completed with undelivered notifications.
Received broadcast but no handler is configured method=thread-stream-state-changed
[desktop-notifications][global-error] ResizeObserver loop completed with undelivered notifications.

The same log also contains a feature/config version mismatch:

codex_features: unknown feature key in config: thread_tools

The kernel records an invalid-opcode trap in a code --type=renderer process using Wayland:

traps: code[...] trap invalid opcode ... in code[...]

Core analysis shows the faulting instruction is an explicit ud2, preceded by int3. After rebasing the ASLR addresses, all three cores land at the same ELF virtual offset, 0x3ac5667:

int3
ud2    # faulting instruction

The binary is stripped, but nearby embedded trace strings identify this code region as Blink style/layout code, including:

Style.InvalidationTime
UpdateLayoutTree

The Codex app-server stays alive after the renderer dies. No OOM kill is recorded, and neither the VS Code main process nor GPU process crashes.

Environment

  • OS: NixOS 26.05.20260712.569d578 (Yarara)
  • Kernel: Linux 7.1.3, x86_64
  • Desktop: Wayland
  • CPU: AMD Ryzen 7 5800H
  • VS Code: 1.128.0
  • VS Code commit: fc3def6774c76082adf699d366f31a557ce5573f
  • Codex extension: openai.chatgpt 26.707.41301
  • Extension-bundled Codex CLI: 0.144.0-alpha.4
  • Standalone Codex CLI installed on the host: 0.144.1
  • Codex setting: chatgpt.followUpQueueMode = steer (included for completeness; not established as causal)

Working hypothesis

The repeated stream-state broadcasts appear to drive or amplify frontend DOM/layout updates while a ResizeObserver delivery is already in progress. Blink then reaches an internal style/layout invariant and intentionally aborts with ud2. The unsupported thread_tools feature and missing thread-stream-state-changed handler also suggest the extension frontend and bundled app-server may have incompatible feature/event expectations.

This is an inference from the timing and native-core evidence, not yet a minimal source-level reproduction.

Related reports

I did not find an existing issue with this exact ResizeObserver -> Blink UpdateLayoutTree -> SIGILL signature. These appear related:

I can provide sanitized full extension logs and additional core/disassembly details if useful.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

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

  • #32502

Powered by Codex Action

sharkdingo · 1 month ago

Windows reproduction of the same unhandled stream-state / ResizeObserver pattern, ending in a blank gray Codex webview.

Environment

  • Windows 11 25H2, build 26200.8875, x64
  • VS Code 1.129.0
  • Codex extension openai.chatgpt 26.707.91948
  • Bundled codex-cli 0.144.5

Observed behavior

  1. Resume and switch between existing Codex conversations while turns are active.
  2. The Codex panel becomes a uniform gray/blank content area.
  3. The VS Code shell remains drawn and usable; the Codex content does not render.

At the time of the gray panel:

  • All sampled Code.exe processes reported Responding=True.
  • codex.exe remained alive and responsive.
  • No Code.exe Application Error/Hang event was recorded.
  • About 4.98 GB RAM was available; CPU was 6-11% and disk activity 1-3%, so this was not an OOM or system saturation event.

The Codex extension log produced 213 lines in about two minutes, including:

  • 131 occurrences of:

``text
[IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed
``

  • 6 occurrences of:

``text
[desktop-notifications][global-error] ResizeObserver loop completed with undelivered notifications.
``

  • The same feature mismatch:

``text
codex_features: unknown feature key in config: thread_tools
``

Updates from two conversation IDs were interleaved in the log while the panel was switching visibility/ownership. This looks like a frontend/webview failure or event-handling loop rather than the app-server exiting.

For completeness, VS Code also reported its extension host unresponsive for about 3.2 seconds during startup, but it recovered before the Codex extension activated, so I am not attributing that startup pause to Codex.

No raw conversation logs or account data are attached.

lishiao144 · 17 days ago

Windows reproduction with a source-level lead and local mitigation

I have reproduced the same blank Codex webview failure on Windows. I also inspected the currently installed extension after updating and found that the same synchronous layout path is still present.

Environment

  • Windows host
  • VS Code 1.130.0
  • Remote-SSH target
  • Codex extension openai.chatgpt 26.5803.61601

Observed behavior

  • While a response is streaming and the conversation height changes repeatedly, the Codex panel becomes completely blank.
  • The VS Code workbench remains usable.
  • The remote extension host and Codex app-server remain alive and continue logging after the UI disappears.
  • Restarting or reloading the webview restores the panel temporarily.

The active extension log contained 132 occurrences of:

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

These errors appeared in bursts around incremental reasoning/turn updates.

I also have two recent Windows Crashpad dumps from this failure. Both identify the failed process as renderer / vscode-webview, with exception 0x80000003 at the same relative location:

Code.exe+0x21E5CC0

The renderer had approximately 642-760 MiB committed and 230-328 MiB private memory. The VS Code main process, extension host, and Codex app-server stayed alive, so this does not look like a normal OOM or backend crash.

Source-level lead

In the bundled conversation-source-*.js, the conversation height/layout handler creates a React state/layout update callback and executes it using this logic:

sync ? flushSync(updateLayoutState) : updateLayoutState();

The ResizeObserver path invokes this handler without overriding the sync argument, whose default is true. As a result, ResizeObserver delivery can call flushSync and synchronously mutate React state/DOM layout while the observer callback is still being delivered.

That creates a re-entrant ResizeObserver/layout cycle and matches the repeated “undelivered notifications” errors immediately preceding the blank webview/renderer failure.

In the current minified asset, the relevant expression is:

r ? (0, De.flushSync)(j) : j()

Local mitigation

I changed that expression locally to defer the observer-triggered update to the next task:

- r ? (0, De.flushSync)(j) : j()
+ r ? setTimeout(j) : j()

The patched webview assets pass syntax validation using the Node.js runtime bundled with VS Code Server. This removes the synchronous React/layout mutation from ResizeObserver delivery.

I have not completed a long stress run after the latest extension update, so this should be treated as a concrete source-level lead and local mitigation rather than a fully validated upstream fix. Extension updates replace the hashed webview assets and restore the original flushSync path, so the observer-driven height update still needs an upstream guard or deferred scheduling fix.