[VS Code extension][Windows 11] Streaming UI stalls/no token-by-token updates; repeated `thread-stream-state-changed` broadcasts with no handler

[kirilllopoukhov49-crypto]

What version of the IDE extension are you using?

openai.chatgpt 0.4.79 (also observed previously on 0.5.79)

What subscription do you have?

ChatGPT Business (member)

Which IDE are you using?

VS Code 1.109.5 (072586267e68ece9a47aa43f8c108e0dcbf44622, x64)

What platform is your computer?

Windows 11 Pro 25H2 (build 26200.7840)

What issue are you seeing?

Codex in VS Code does not stream assistant output progressively. Messages are often rendered only at the end, or UI updates are delayed until user interaction (click/focus/change in UI).

Reproduces in a fully pristine VS Code profile with only the Codex extension installed.

Actual behavior:

• Streaming is effectively broken in UI (message appears in bulk / at end).
• Output -> Codex warning flood:
  • Received broadcast but no handler is configured method=thread-stream-state-changed
• Repeated errors:
  • local-environments is not supported in the extension

Key log evidence (from attached bundle, logs/Codex.log):

• thread-stream-state-changed: 193
• client-status-changed: 1
• local-environments is not supported: 2
• startup websocket prewarm setup failed: 0
• stream disconnected - retrying sampling request: 0
• falling back to HTTP: 0

What steps can reproduce the bug?

Pristine profile repro:

1. Launch VS Code with a new empty --user-data-dir and --extensions-dir.
2. Install only openai.chatgpt@0.4.79.
3. Sign in with ChatGPT login (no API key).
4. Open Codex chat and ask for a longer response (e.g., “List numbers 1..200, each on a new line”).
5. Observe that output is not rendered token-by-token in the UI.

What is the expected behavior?

• Token-by-token streaming in the Codex webview without requiring user interaction.
• No unhandled broadcast spam for stream state changes.

Additional information

What was already tried:

• VS Code reload/restart.
• Single window only (no WSL/Remote-SSH windows open).
• Workspace storage reset.
• Extension reinstall/downgrade/upgrade (0.4.79 / 0.5.79).
• Clean profile with isolated CODEX_HOME and isolated extensions dir.
• Disabling potential local interference (e.g., VPN service process) did not resolve.

Regression signal:

• User reports issue started after first usage with additional Remote-SSH window(s).
• After that point, issue persisted even in local-only and pristine profile scenarios.

Attachments:

• codex-streaming-diagnostics-safe-20260303-155648.zip (logs/Codex.log, logs/exthost.log, HIGHLIGHTS.txt, extension-metadata/package.json)

codex-streaming-diagnostics-safe-20260303-155648.zip

[kirilllopoukhov49-crypto]

I managed to pin down the root cause and build a working workaround.

Symptom

Streaming deltas arrive continuously (I instrumented the webview and can see a flush happening on every delta), but the UI does not re-render while streaming. New tokens only appear:

• in one big chunk at the end, or
• in batches after any “discrete” user interaction inside the Codex webview (clicking the assistant text / “Thinking” / model selector / scrolling).

This makes it look like “streaming is stuck until click”, but the data is actually already in the store.

Root cause (webview subscription bug)

The webview components that render the conversation were not subscribed to per-conversation updates. They effectively reacted to “registry/manager presence” (or similar) but not to “conversation X changed”.
As a result, state updated in the manager/store during streaming, but React didn’t get onStoreChange for that conversation, so no re-render happened. Any random interaction triggered a local re-render and the component re-read the latest state → tokens appeared in a batch.

Working fix / workaround

Make the webview hook(s) subscribe via the manager’s per-conversation callback, e.g.:

• manager.addConversationCallback(conversationId, onStoreChange)

(Optionally also keep the registry callback as a fallback in case the manager becomes available later, but the key is subscribing to the conversation’s updates.)

After changing the hook(s) to use the per-conversation callback, streaming works normally without clicks.

Why it might be “only for some users”

This seems like a timing/race issue: on some machines/builds the UI happens to re-render often enough that the bug is masked; on my setup it doesn’t, so the issue is obvious.

My environment

• Windows 11 25H2 (build 26200.x)
• VS Code 1.109.5 (also reproduced on Insiders)
• Codex extension 0.4.79 / 0.5.79

If you want, I can share the exact patched snippet / diff in webview/assets/index-*.js, but the conceptual fix is “subscribe to conversation updates, not only registry/manager presence”.

[skyler-ashkore]

Seconded!

I am also having this issue.

VS Code Version: 1.109.5 (user setup)
Electron: 39.3.0
ElectronBuildId: 13313481
Chromium: 142.0.7444.265
Node.js: 22.21.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200
Codex extension 0.4.79

[nikpag]

I'm also having this issue as of today:

Version: 1.110.0 (Universal)
Commit: 0870c2a0c7c0564e7631bfed2675573a94ba4455
Date: 2026-03-04T01:20:28.863Z (20 hrs ago)
Electron: 39.6.0
ElectronBuildId: 13330601
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.3.0
Codex extension: 0.4.79

[hairoi]

I'm also having this issue.

Version: 1.109.5 (user setup)
Commit: 072586267e68ece9a47aa43f8c108e0dcbf44622
Date: 2026-02-19T19:43:32.382Z
Electron: 39.3.0
ElectronBuildId: 13313481
Chromium: 142.0.7444.265
Node.js: 22.21.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26100
Codex extension 0.4.79

[maxmerixa-ctrl]

I reproduced the same behavior and found a likely root cause:
webview conversation UI is not subscribed to per-conversation updates during streaming.
Workaround that fixes it locally:
manager.addConversationCallback(conversationId, onStoreChange) (+ cleanup, optional registry fallback for re-attach).

Environment:

• Windows 11 25H2 (26200.x)
• VS Code 1.109.5
• Codex extension 0.4.79 / 0.5.79

Logs include repeated:
[IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed

[bcdonadio]

Same issue here:

Version: 1.110.0
Commit: 0870c2a0c7c0564e7631bfed2675573a94ba4455
Date: 2026-03-04T01:20:28.863Z
Electron: 39.6.0
ElectronBuildId: 13330601
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Linux x64 6.18.12-100.fc42.x86_64
Codex Extension: 0.4.79

@maxmerixa-ctrl Where exactly did you insert this line to work around this bug?

[maxmerixa-ctrl]

It didn’t work for me in the end.

What fixed it on my side was downgrading the extension. I installed Codex Extension 0.4.74, then ran Reload Window and Restart Extension Host in VS Code. After that, the step streaming started working again and I can see actions like reading/editing/running commands in real time.

Environment (for reference):
VS Code 1.110.0, Codex Extension 0.4.79 originally → downgraded to 0.4.74.

[Grunticus03]

Same issue for me as well.

Version: 1.106.0 (user setup)
Commit: ac4cbdf48759c7d8c3eb91ffe6bb04316e263c57
Date: 2025-11-11T16:02:25.943Z
Electron: 37.7.0
ElectronBuildId: 12597478
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Windows_NT x64 10.0.26200

Downgrading to 0.4.78 is my current workaround.