VS Code extension webview fails to mount, reports unknown openai-codex session, and floods IPC broadcasts on Windows

Summary

The VS Code Codex extension appears to start its backend/app-server, but the Codex webview frontend does not mount. The extension then receives a large number of unhandled IPC broadcasts, VS Code reports the window as unresponsive, and later reports openai-codex as an unknown chat session type even though the extension contributes that chat session type.

This is not presenting as a general VS Code/plugin failure on this machine. The failing logs are concentrated around openai.chatgpt / Codex.

Environment

• OS: Windows NT 10.0.19045.0 x64
• VS Code: 1.127.0, commit 4fe60c8b1cdac1c4c174f2fb180d0d758272d713
• Extension: openai.chatgpt
• Extension version: 26.623.101652
• Extension package declares contributes.chatSessions.type = "openai-codex"
• Activation event: onView:chatgpt.sidebarSecondaryView

Impact

Opening the Codex side panel repeatedly causes VS Code to show "Window is not responding". The Codex panel stays blank/unusable or enters an unknown-error state.

Timeline from logs

• 2026-07-05 14:12:27.873: VS Code activates openai.chatgpt via onView:chatgpt.sidebarSecondaryView.
• 2026-07-05 14:12:28.053: Codex extension activates and spawns Codex app-server.
• 2026-07-05 14:12:28.062 onward: Codex log records repeated IPC broadcasts with no handler.
• 2026-07-05 14:18:49.448: VS Code logs CodeWindow: detected unresponsive.
• 2026-07-05 14:19:04.449: VS Code logs UnresponsiveSampleError for window ID 3 / renderer PID 30244.
• Later in the same session, renderer reports Attempted to report in-progress status for unknown chat session type 'openai-codex'.
• The UI later shows a generic unknown error; logs include TypeError: e is not iterable.

Key log excerpts

2026-07-05 14:12:27.873 [info] ExtensionService#_doActivateExtension openai.chatgpt, activationEvent: 'onView:chatgpt.sidebarSecondaryView'
2026-07-05 14:12:28.053 [info] Activating Codex extension
2026-07-05 14:12:28.053 [info] [CodexMcpConnection] Spawning codex app-server
2026-07-05 14:12:28.062 [warning] [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed

2026-07-05 14:18:49.448 [error] CodeWindow: detected unresponsive
2026-07-05 14:19:04.449 [error] [uncaught exception in main]: UnresponsiveSampleError: UnresponsiveSampleError: from window with ID 3 belonging to process with pid 30244

2026-07-05 14:55:05.726 [warning] Attempted to report in-progress status for unknown chat session type 'openai-codex'
2026-07-05 14:55:09.190 [error] Error: e is not iterable
TypeError: e is not iterable

Observed counters from latest failing Codex log

• Total sampled Codex log lines: 1922
• IPC warnings: 1917
• Dominant method: thread-stream-state-changed=1913
• React root render requested: 0
• app routes mounted: 0
• ready: 0

During a later 14:18-14:22 window, the Codex log contained 1556 IPC warnings, almost all thread-stream-state-changed. This is strongly correlated with the bad session, though a renderer CPU profile / IPC queue metrics would be needed to prove strict causality.

Expected webview startup chain

From the bundled extension/webview code, the expected chain appears to be:

1. VS Code triggers the Codex side view and the extension resolves the webview.
2. The extension enables scripts, registers onDidReceiveMessage, and assigns webview.html.
3. index.html loads assets/index-*.js.
4. The index bundle dynamically imports app-main-*.js.
5. app-main initializes and logs React root render requested.
6. App routes mount, log app routes mounted, then send ready.
7. The extension marks the sidebar webview ready and flushes pending sidebar messages.

Older logs from the same machine show this chain can work:

React root render requested
[startup][renderer] app routes mounted after 4740ms

The current failing session does not emit renderer global-error, unhandled-rejection, React root render requested, app routes mounted, or ready, so the failure is before or during early webview bootstrap.

Actual result

• Codex backend/app-server starts.
• Webview frontend does not reach React bootstrap.
• openai-codex is later reported as an unknown chat session type despite being contributed by the extension.
• thread-stream-state-changed broadcasts are received without registered handlers.
• VS Code renderer becomes unresponsive.
• The user sees a blank/unusable panel or generic unknown error.

Expected result

• The Codex webview should mount or show a concrete Codex-specific bootstrap error.
• openai-codex chat session registration should remain available across extension host restarts/reloads.
• IPC broadcasts should be gated, handled, coalesced, or dropped safely until the webview/session consumer is ready.
• A failure in early webview bootstrap should not flood logs or make the VS Code window unresponsive.

Requested fixes / investigation points

Please investigate:

1. Webview frontend bootstrap before React root render requested.
2. Whether dynamic import / CSP / module load failures can occur before error handlers are installed.
3. Registration order for IPC broadcast handlers, especially thread-stream-state-changed.
4. Ready gating for app-server broadcasts until the webview has sent ready.
5. Backpressure/coalescing for high-volume state broadcasts.
6. openai-codex chat session registration lifecycle across extension host restarts/reloads.
7. The TypeError: e is not iterable path so malformed/missing session data becomes a recoverable Codex-specific error.

Recommended engineering changes:

• Register thread-stream-state-changed, thread-read-state-changed, and client-status-changed handlers before subscribing to app-server broadcasts.
• Do not send stream/read state broadcasts to a client until its webview/session consumer is ready.
• Coalesce state broadcasts with last-write-wins semantics and rate-limit to a bounded frequency.
• Add IPC queue backpressure and counters for sent/dropped/coalesced events.
• Rate-limit "no handler" warnings into periodic summaries.
• Add early webview bootstrap logging before dynamic import, catch import failures, and report CSP/module load failures back to the extension host.
• Add a render fail-open timeout around early config/feature initialization so React render is not blocked indefinitely.
• Add a host-side ready watchdog that shows a Codex-specific diagnostic view when ready is not received.