Windows VS Code: multiple Codex editor tabs fail with renderer_ready_timeout in 26.901.22334

What version of the IDE extension are you using?

openai.chatgpt 26.901.22334 (win32-x64). The same timeout was also recorded locally with 26.825.51511.

What subscription do you have?

ChatGPT account; exact subscription tier is not included in this public report.

Which IDE are you using?

Visual Studio Code 1.136.1, local Windows installation.

What platform is your computer?

Windows 10 Pro, build 10.0.19045, x64.

What issue are you seeing?

With several Codex conversation editor tabs open, some tabs display:

Codex could not start
The extension could not start its user interface.

This repeatedly interrupts my work. In the latest captured occurrence there were three Codex editor tabs. One renderer mounted, while two panel renderers timed out almost simultaneously. I cannot establish an actual two-chat limit from this evidence.

Relevant local log excerpts, with account, project, and filesystem details omitted (timestamps UTC+05:00):

2026-09-06 00:01:57.157 [info] Activating Codex extension
2026-09-06 00:02:00.817 [info] [startup][renderer] app routes mounted after 2818ms
2026-09-06 00:02:27.743 [error] [CodexWebviewProvider] Webview renderer did not become ready elapsedMs=30002 extensionVersion=26.901.22334 reason=renderer_ready_timeout receivedWebviewMessage=false role=panel stage=renderer timeoutMs=30000
2026-09-06 00:02:27.744 [error] [CodexWebviewProvider] Webview renderer did not become ready elapsedMs=30003 extensionVersion=26.901.22334 reason=renderer_ready_timeout receivedWebviewMessage=false role=panel stage=renderer timeoutMs=30000

What steps can reproduce the bug?

Observed scenario, not yet a deterministic minimal reproduction:

1. Use the Codex IDE extension on local Windows in VS Code.
2. Have multiple Codex conversation editor tabs open, including tabs that are not currently selected.
3. After extension/window startup, switch between the conversation tabs.
4. Affected tabs show the generic startup failure; the log records the 30-second panel-renderer timeout above.

The exact role of inactive/restored tabs is unconfirmed. I have not verified the issue in a clean VS Code profile or with every other extension disabled.

What is the expected behavior?

Multiple conversation tabs should initialize or resume reliably. A delayed or inactive panel should remain recoverable instead of being replaced with a terminal error page. Please provide a safe way to retry the affected tab without restarting other working conversations.

Additional information

• Inspection of the installed extension confirms that this error page is produced by its 30-second renderer-readiness watchdog. This establishes the failure mechanism, not the underlying cause.
• A local helper extension is installed to open unique conversation-editor URIs using vscode.openWith and chatgpt.conversationEditor. Its role has not been ruled out; it is disclosed here to avoid claiming a clean configuration.
• Related reports found before filing: #40532 concerns Dev Containers/sidebar initialization; #37458 concerns an earlier Windows resource-loading failure and is closed. This report concerns local Windows conversation panels in a newer version. If it is the same underlying issue, please link or merge it with the appropriate report.
• No private chat contents, project names, full logs, credentials, account identifiers, or screenshots containing workspace titles are attached.

Could the team please triage this, confirm whether concurrent editor tabs are supported, and provide a workaround or fixed-version guidance? If additional diagnostics are needed, please specify the smallest useful sanitized log or reproduction procedure. Thank you.

Start with the CodexWebviewProvider renderer-readiness watchdog and the 30-second renderer_ready_timeout logs described in the report. Reproduce with multiple conversation editor tabs using vscode.openWith and chatgpt.conversationEditor, then compare behavior in a clean VS Code profile. Done means identifying a reliable cause and providing a recoverable retry path or confirmed fixed-version guidance.