›_ Codex Issues
Codex Issues / #40532

[Regression] IDE extension 26.818.61809 hits renderer_ready_timeout in VS Code Dev Containers

Open 💬 0 comments Opened Aug 25, 2026 by KajiMaCN

What version of the IDE extension are you using?

openai.chatgpt-26.818.61809-linux-x64

Bundled CLI:

codex-cli 0.149.0-alpha.4.3

What subscription do you have?

ChatGPT subscription (the failure occurs before the sidebar UI becomes ready).

Which IDE are you using?

Visual Studio Code 1.134.0

  • Commit: 110a328ea54b42367b803ec53ee0bf52ef26b419
  • Context: VS Code Dev Containers

What platform is your computer?

  • Client: Windows x64
  • Remote Dev Container: Ubuntu 22.04.5 LTS, Linux 6.8.0, x86_64

What issue are you seeing?

After the extension auto-updated to 26.818.61809, the Codex sidebar stopped starting and displayed:

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

The extension host and bundled Codex app-server start successfully, but the webview never sends its ready handshake. After 30 seconds, Codex.log records:

2026-08-25 11:21:20.659 [info] Activating Codex extension
2026-08-25 11:21:20.659 [info] [CodexMcpConnection] Spawning codex app-server
2026-08-25 11:21:20.659 [info] [CodexMcpConnection] Initialize received id=1
2026-08-25 11:21:54.933 [error] [CodexWebviewProvider] Webview renderer did not become ready elapsedMs=30000 extensionVersion=26.818.61809 reason=renderer_ready_timeout receivedWebviewMessage=false role=sidebar stage=renderer timeoutMs=30000

This appears to be a regression/reintroduction of the startup-readiness problem tracked in #37458, which was reported fixed in 26.810.41047.

The shipped bundle still gates initial rendering on an unresolved startup promise. In:

webview/assets/app-main-BBpAhtwM.js

the following expression appears exactly once:

let e=G||K||_.startup?.whenReady==null?void 0:Promise.resolve(_.startup.whenReady());

In this environment, _.startup.whenReady() does not resolve, so the renderer never reaches the ready handshake and the host watchdog replaces the sidebar with the error page.

What steps can reproduce the bug?

  1. Use VS Code 1.134.0 on Windows.
  2. Connect to an Ubuntu 22.04 x86_64 Dev Container.
  3. Install or auto-update the Codex IDE extension to 26.818.61809-linux-x64.
  4. Fully restart VS Code and reconnect to the container.
  5. Open the Codex sidebar.
  6. Wait approximately 30 seconds.
  7. Observe the generic startup error and renderer_ready_timeout in Codex.log.

Reinstalling the extension and removing older extension/VS Code Server versions do not fix the problem.

What is the expected behavior?

The webview should complete initialization and send the ready handshake. If an account, networking, feature bootstrap, or startup dependency remains pending, it should use a bounded timeout and render a recoverable/offline error state rather than block the entire sidebar until the outer 30-second watchdog fires.

Additional information

A version-specific local workaround confirms the failure is in this startup gate. After backing up the bundle, replacing the expression above with:

c.dispatchMessage(`ready`,{});let e=void 0;

and fully restarting VS Code, the sidebar starts normally. The bundle then contains one explicit ready dispatch and no remaining delayed startup.whenReady() gate.

This workaround is necessarily reapplied after extension updates and is not intended as a production fix. Please restore the bounded/fallback startup behavior so future updates do not reintroduce the deadlock.

Related report and earlier workaround analysis:

No private hostnames, IP addresses, credentials, tokens, or project paths are included in this report.

View original on GitHub ↗