Codex Could Not Start in VS Code: What the Error Means and How to Fix It

"Codex could not start. The extension could not start its user interface" is a generic page that the Codex IDE extension shows when its sidebar webview does not report ready within about 30 seconds. It is not one bug. The same screen has been filed against Windows installs, Dev Containers, Remote SSH and Cursor, each with a different cause. The query "codex could not start" went from near zero to a relative interest of 47 on October 26 and 27 in Google Trends (read October 31, 2026, index of 100 at the peak of the compared set; "claude code skills" sat around 65 over the same days), and the related query "codex could not start its user interface" was listed at +2,050% for the past 7 days.

The fix depends on which layer failed. Read the log line first, then jump to the matching section below.

What the error actually means#

In the GitHub issue that tracked the August regression, a user analysing the extension source reports that initializeWebview sets a 30-second timeout and requires a ready message from the webview inside that window. Miss it and the host swaps the sidebar for the error page. A later report in issue 40532 shows the matching log line:

[CodexWebviewProvider] Webview renderer did not become ready
elapsedMs=30000 reason=renderer_ready_timeout receivedWebviewMessage=false role=sidebar

Notice what that log shows: the extension host started and the bundled codex app-server initialized. Only the webview never answered. So "Codex could not start" says the user interface failed, not that your account, model access or CLI is broken. That is why reinstalling the extension so often does nothing: the backend was fine.

Step 1: read the log before you change anything#

Open View > Output, choose Codex from the dropdown, and reproduce the failure once. Look for the first error, not the last generic one. The match table:

Fix 1: update, then reload, in that order#

OpenAI's maintainer comment pinned on the issue says a release (26.810.41047 stable) fixed the startup watchdog so initialization taking longer than 30 seconds no longer produces the resource-loading error by itself. The same comment warns that if a networking or authentication problem was blocking initialization, that problem remains.

So: update the extension from the Extensions view, then run Developer: Reload Window from the Command Palette. If a fresh VS Code window with a clean profile works, the problem is state in your normal profile, not the extension.

Fix 2: roll back one version if it started after an auto-update#

The original August reports describe a clean break: the panel worked, the extension auto-updated, and the panel failed. One reporter restored service by installing the previous VSIX directly. In the Extensions view, use Install Another Version on Codex and pick the build from before the failure. Then turn off auto-update for that extension until a newer build lands. Record the failing version first so a bug report is useful.

One caution from the thread itself: some users could not roll back because the VSIX download was cancelled. If that happens, pull the VSIX from the marketplace page instead.

Fix 3: Dev Containers need their own check#

The issue 40532 reporter hit the timeout inside a VS Code Dev Container after the extension auto-updated to 26.818.61809, and says reinstalling and clearing older server versions did not help. The reporter's analysis points at a startup promise that never resolves in that environment. The reporter also describes hand-editing the shipped JavaScript bundle as a workaround and labels it unsuitable as a production fix, because it needs reapplying after every update. I would not do that. Instead, rebuild the container so the matching extension version installs fresh, try the previous extension version inside the container, and watch the issue for a fix. The issue was still open when I read it.

Fix 4: Remote SSH, restart the narrowest layer#

A Remote SSH write-up by JP Pinto lays out a safe order, and it matches Microsoft's own remote-development troubleshooting guidance:

1. Developer: Restart Extension Host
2. Developer: Reload Window
3. Check the Codex, Remote - SSH and remote extension-host logs
4. Remote-SSH: Kill VS Code Server on Host..., then reconnect
5. Only then, a targeted kill -TERM <PID> on the exact stale process

To find the right process, use the read-only listing from that guide:

ps -u "$USER" -o pid,ppid,etimes,%cpu,%mem,args --forest \
  | grep -E 'vscode-server|code-server|extensionHost|openai\.chatgpt|codex' \
  | grep -v grep

That guide specifically warns against a broad pkill -u "$USER" -f 'vscode-server|code-server' on shared accounts because it can take out unrelated sessions. Agree. It also notes Codex over Remote SSH is normally a child of the remote extension host, not a systemctl service, so restarting Nginx or databases will not help.

Fix 5: Cursor, where the host rejects the sidebar#

A Cursor forum bug report from October 28 describes Cursor 3.27.22 on Windows rejecting the extension's secondary-sidebar container. The logged message says the secondary sidebar is reserved for Cursor's agent UI and extensions should contribute to the activity bar or panel instead. The backend initializes, the container does not exist, and the webview then times out. The reporter had already tried an extension host restart and a window reload. This is a host-versus-extension compatibility problem, not something a reinstall fixes. For now the pragmatic options are running Codex in plain VS Code or using the Codex CLI in a terminal while the two vendors sort out the container. See our Claude Code vs Cursor vs Codex comparison if you are deciding which editor to standardize on.

Fix 6: when it is really network or auth#

If the first error is fetch failed, ECONNRESET or 403 Forbidden, no UI fix will help. The Remote SSH guide separates these cleanly: a renderer timeout is local to the webview or extension host, while a 403 means a server refused the request, so check the signed-in account, workspace policy and proxy. The OpenAI maintainer comment above also points at proxy and VPN settings. Test HTTPS egress from the same machine the extension runs on, which in a remote window is the remote host, not your laptop.

What people are actually saying#

• On r/codex, threads such as Codex CLI in VSCode failing to start? and a post titled "[FIX] VSCode extension not loading Codex chat sessions" show the same symptom recurring week to week, mostly from Windows users (read via search excerpts, October 31, 2026).
• On the Cursor side, the forum's related-topics list for the Codex sidebar shows a run of reports back to Cursor 3.15.6, so this is a recurring compatibility problem rather than one bad release.
• The counter-case: not every stuck Codex panel is this error. One r/codex thread (endless loading) attributes a loading hang to the model picker allowing a reasoning effort the model does not support. That is a different bug with a different fix, and the 30-second error page is how you tell them apart.

What to do Monday#

1. Keep the CLI installed as a fallback. If the sidebar breaks, codex in a terminal still works, and our headless Codex guide covers scripted use.
2. Turn off extension auto-update for Codex on any machine you cannot afford to lose a morning on, and update deliberately.
3. When you file a bug, include the extension version, host version (VS Code or Cursor), local vs remote vs container, and the first error from the Codex output channel.

Continue Reading#

• Codex at 8 million users: developer guide - what the product looks like at scale
• Claude Code vs Cursor vs Codex - how the three editors-and-agents compare
• Codex exec for CI and headless runs - the terminal path when the sidebar is down
• Codex gpt-5.5 model-not-supported error: the fix - the other Codex error people paste into search
• Codex CLI 0.164 presets and permissions - recent CLI changes

FAQ#

What does "Codex could not start. The extension could not start its user interface" mean?#

The Codex sidebar webview did not signal ready within roughly 30 seconds, so the extension replaced it with a generic error page. The backend can be healthy while this happens.

Will reinstalling the Codex extension fix it?#

Sometimes, but several reporters in the GitHub issues reinstalled with no change. Read the Codex output log first and match it to the cause.

Why does it only fail over Remote SSH or in a Dev Container?#

The extension, VS Code Server and webview run in separate places, and a stale remote extension host or a build-specific startup issue can break only that path. Restart the extension host, then kill the VS Code Server on the host.

Does Codex work in Cursor?#

A Cursor forum report says Cursor 3.27.22 rejects the extension's secondary-sidebar container, which leaves the UI unable to start. Plain VS Code or the Codex CLI avoid it.

Sources#