You open the Codex sidebar in VS Code and, instead of the chat, you get this notification:
Codex could not start
The extension could not start its user interface.Since 10/24/2026, the most common cause is a version bug in the openai.chatgpt extension, not your account or your network. The fix that worked most often in the reports is to roll back to version 26.1007.21434 and turn off auto update for that one extension. There is no published fix yet: when I queried the VS Marketplace on 10/26/2026, the latest version was still 26.51021.22027.
What does "Codex could not start" mean in VS Code?
It means the Codex process started, but the interface (the sidebar webview) was not ready within 30 seconds. The extension gives up and shows the notification. The problem is in the screen, not in the agent.
To confirm, open the VS Code Output panel (View > Output) and pick the Codex channel. In issues #56691, #56655 and #56660 the log always has the same signature: the backend initializes and, 30 seconds later, the error appears.
[CodexMcpConnection] Initialize received id=1
[CodexWebviewProvider] Webview renderer did not become ready
elapsedMs=30002 extensionVersion=26.1021.22027
reason=renderer_ready_timeout receivedWebviewMessage=false
role=sidebar stage=renderer timeoutMs=30000If your log shows renderer_ready_timeout, this is your case. If the error is different, so is the problem, and this walkthrough does not apply.
Which versions are affected?
The ones reported in the issues are stable 26.1021.22027 and pre-release 26.51021.22027, both published on the VS Marketplace on 10/23/2026. The earlier ones, 26.1007.21434 and 26.51007.21434, date from 10/09/2026 and work for most people.
| Version | Channel | Status in the reports |
|---|---|---|
| 26.1007.21434 | Stable | Works. Used for the rollback |
| 26.51007.21434 | Pre-release | Works |
| 26.1021.22027 | Stable | Fails with renderer_ready_timeout |
| 26.51021.22027 | Pre-release | Fails with renderer_ready_timeout |
Reports come from Windows 10 and 11, Intel macOS, Linux, Remote SSH and even Antigravity with WSL (issue #56617). In the VS Code cases, the versions are 1.142 and 1.143.
How do I roll back to the version that works?
Run the command below in a terminal and restart VS Code. It is what the authors of issues #56691 and #56660 used, and it restored the interface in their reports.
code --install-extension openai.chatgpt@26.1007.21434 --forceIf you prefer the UI: in the Extensions tab, right-click Codex and choose Install Another Version, as described in the VS Code documentation. Select 26.1007.21434.
How do I stop VS Code from updating it back?
Without this, auto update reinstalls the broken version. In the Extensions tab, right-click Codex and uncheck Auto Update. It applies only to that extension; the others keep updating. When OpenAI publishes a new version, turn it back on and check the log.
Heads up: the @version form of the command comes from the issue reports, not from the VS Code extensions documentation page. If your code rejects it, use Install Another Version in the UI.
What if the old version also fails?
Then the trigger is different, and the issues report two paths. Neither is official; they are what worked for the people who posted.
1. Clear the webview cache. A Fedora user (VS Code 1.143.1) measured the webview cache at 856 MB, holding files from 29 extension versions, and clearing it fixed the problem without a rollback (issue #56660). With VS Code fully closed, move the WebStorage and Service Worker folders to a backup. On Linux they live in ~/.config/Code; on Windows, in %APPDATA%\Code; on macOS, in ~/Library/Application Support/Code.
# Linux (with VS Code closed)
mv ~/.config/Code/WebStorage ~/.config/Code/WebStorage.bak
mv ~/.config/Code/"Service Worker" ~/.config/Code/"Service Worker.bak"The first launch afterwards is slower (about 24 seconds in that report) while the cache rebuilds. Since it is a backup, you can undo it by moving the folders back.
2. Roll VS Code itself back to 1.142. A Windows 11 user documented that, on VS Code 1.143.1, even extension 26.1007.21434 started timing out, and that on 1.142.0 the interface opened in about 2 seconds. Another report confirms the same on Linux. That points to 1.143.1 also being part of the equation (issues #56655 and #56691).
Why does it happen?
The cause is not confirmed by OpenAI. Reports in issues #57026 and #56655 measure a packaging difference: the 26.1021.22027 webview preloads 3,203 files (about 73 MB), against about 6 JavaScript files (about 20 MB) in 26.51007.21434. With that much to load, the 30-second deadline blows on slower machines or with a full cache. That is a hypothesis from users, not a diagnosis from the Codex team.
What can I do while Codex won't open?
If you need to work right now, you don't have to wait for the fix. Verboo Code runs as a CLI in the terminal, with no VS Code webview to hang, and with unlimited tokens. You can set Codex aside until OpenAI publishes a version that opens.
