Codex "Couldn't Load Its Resources": 5 Causes to Fix (2026)

TL;DR

Error text:          "Codex could not start. The extension couldn't load its resources."
What it really means: Webview did not send its ready handshake within 30s
Broken versions:      26.803.41515 (2026-08-07), 26.803.61601 (2026-08-10)
Fixed in:             26.810.41047 stable / 26.5810.41047 pre-release (2026-08-13)
Latest stable:        26.810.52044 (2026-08-15)
Safe rollback target: 26.727.40816 (2026-07-30)
Distinct root causes: 5 (watchdog, proxy, pending auth, webview cache, Copilot conflict)
Fixes that do nothing: deleting auth.json, chasing the data:font CSP warning
Still open upstream:   openai/codex#37521 (pending account identity)

If your Codex sidebar in VS Code sat spinning for half a minute and then collapsed into a grey panel reading “The extension couldn’t load its resources,” the message misled you. The resources loaded. What failed was a handshake, and the extension host had a stopwatch running.

The error message was the bug’s best disguise. Codex was not failing to find its files, it was failing to hear back from a window that had already loaded them.

This piece covers the August 2026 regression specifically: which builds carry it, what OpenAI actually changed to fix it, and the four other failure paths that produce the exact same sentence on screen. If your problem is the CLI binary rather than the editor panel, codex: command not found is the page you want instead. If the Codex desktop app fails to launch its backend on Windows, that is a different error with a different fix.

Which Codex Version Do You Have? The 30-Second Diagnosis

One command tells you, and the answer decides everything else on this page. Run it before you change a single setting.

code --list-extensions --show-versions | grep openai.chatgpt

Version numbers with a 5 prefix on the second segment (26.5810.41047) are pre-release builds of the same code. If you have pre-release enabled in the VS Code Marketplace, 26.5810.41047 carries the same fix as 26.810.41047.

The failure signature to confirm you are looking at the right bug, from Codex.log:

Initialize received
Webview did not finish starting extensionVersion=26.803.41515 role=sidebar

Note what is absent in a failed window. A healthy startup logs three renderer milestones that a failed one never reaches:

React root render requested
app routes mounted
ready provider mounted

If Initialize received appears but none of the three milestones do, the backend is healthy and the browser-side app never booted. That is this bug. If Initialize received is also missing, you have a different problem and the version table above will not help you.

Should You Update, Roll Back, or Wait?

Update. For almost everyone reading this in the aftermath, updating to 26.810.52044 is the whole fix, and the decision is not close.

The three-way rule:

• Update if you are on any 26.803.x build. The fix has been stable through three releases now. This is the default and it is correct roughly nine times out of ten.
• Roll back to 26.727.40816 only if you updated past 26.810.41047, still cannot start the panel, and you have already ruled out proxy and auth causes below. Rolling back is a real option but it is not a diagnosis, and you will have to do this again in a week.
• Stop reading and use the CLI if you need to ship something in the next hour. The extension and the CLI are separate binaries. One being broken tells you nothing about the other.

The stop rule: if you have updated to 26.810.52044 and the panel still will not open, stop trying version permutations. The watchdog that produced this specific error no longer exists in that build. Whatever you are seeing now is one of causes 2 through 5, and more reinstalls will not touch it.

Why Does Codex Say “The Extension Couldn’t Load Its Resources”?

Because a 30-second timer expired, and the message it printed was wrong.

The extension host creates the webview, then waits for that webview to post a ready message back. If the message does not arrive inside the window, the host discards the webview and swaps in a static error page. The page blamed resource loading because that is the most common reason a webview goes silent, not because anyone checked.

The community traced this in the main GitHub thread, which ran to 53 comments over six days before OpenAI closed it. Two competing diagnoses appeared, and the more popular one was wrong in an instructive way.

The first theory pointed at a line in the webview bundle that gates rendering behind startup.whenReady(), and a patch removing it appeared to help. But a later analysis showed the expression short-circuits in VS Code builds. Here is the actual line from app-main-BpHShvzH.js in the affected build:

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

In the VS Code build, the service object never registers startup, so N.startup == null is true, the whole expression evaluates to void 0, and whenReady() is never called. Patching a call that never runs cannot fix anything. It worked by accident, because the patching process rewrote and re-emitted the asset graph as a side effect.

The second theory, which held up, was that the readiness reporter that dispatches {type: "ready"} sat nested below business initialization in the component tree. Anything that stalled app startup, a slow network call, a hung auth request, also stalled the handshake, and the watchdog could not tell the difference between “this window is dead” and “this window is still working.”

A third theory, the data:font/woff2 Content Security Policy warning in the developer console, was a red herring. It appears in healthy windows too. As one contributor put it after collecting logs from both states: the font CSP warning and errors from unrelated extensions are not the startup blocker.

What Changed in 26.810.41047? We Diffed the VSIX

Two things: the 30-second watchdog is gone, and the sentence it printed was rewritten. The webview handshake itself was not rebuilt.

OpenAI’s closing comment says the release “fixes the startup watchdog issue” and that you should no longer see the error “simply because application initialization takes longer than 30 seconds.” That phrasing is precise, and it rewards reading closely.

We downloaded both VSIX packages from the Marketplace (darwin-arm64, 167 MB and 207 MB respectively), plus the pre-regression build for comparison, and counted strings in the extension host bundle extension/out/extension.js:

That first column is the interesting one, and it changes the story. Not one of these strings exists in the July build. The entire error screen, watchdog and wording together, arrived with the regression.

The watchdog was not a long-standing mechanism that started misfiring. It did not exist on 2026-07-30. It shipped on 2026-08-07, mislabelled a class of slow startups as a resource-loading failure for six days, and was removed on 2026-08-13. Both the timer and the sentence it printed were born and buried inside one week.

This also explains why rolling back to 26.727.40816 worked so reliably for people who tried it. They were not rolling back to a version that lacked the bug. They were rolling back to a version that had no stopwatch, so a slow startup stayed slow instead of being killed and relabelled.

Read OpenAI’s phrasing again with that in mind. A recent change exposed an existing bug that was previously masked. The new watchdog is the recent change. The stall it caught is the existing bug, and that one is still out there, which is the whole point of the next section.

The error page itself did not disappear in the fix. Its wording changed:

So the fix has two halves, and only one of them is a fix. The watchdog that gave up at 30 seconds and blamed the assets is gone. The honest replacement text stays, for the cases where the UI genuinely does not come up.

This has a practical consequence that matters more than it sounds: the sentence you searched to find this page no longer exists in current builds. If you are on 26.810.x and seeing “could not start its user interface,” you are not looking at the watchdog bug. You are looking at a real stall, and the causes below are where to go.

One more thing the diff shows. The webview entry point app-main is 2,679 bytes in both builds, with different SHA-256 hashes, and the startup == null short-circuit is present in both. The webview handshake logic was not rewritten. The extension host simply stopped punishing it for being slow.

What Are the 5 Causes Behind This Same Error?

Only the first one was fixed by the August update. The other four are still live, and they were always there.

Cause 1 is the August regression and is now closed. Causes 2 through 5 were always there. Before the fix, all five produced the same misleading sentence, which is exactly why the GitHub thread took six days to converge: people were comparing notes on five different bugs wearing one error message.

Cause 2: Proxy and Network Reachability

This is the most common survivor after updating, and OpenAI called it out by name when closing the issue: check your proxy and VPN settings.

Two distinct proxy failure modes showed up in the thread.

VS Code’s proxy support is switched off. Check your settings.json:

{
  "http.proxySupport": "on"
}

If this is set to "off", the extension cannot use your system proxy. One user found this had been changed while debugging unrelated network issues and had forgotten about it. Setting it back to "on" resolved the hang.

The extension host has no proxy in its environment. Launching VS Code from a shell that exports a proxy fixes this for some setups:

export https_proxy=http://127.0.0.1:9001
code

Launching VS Code from the desktop icon does not inherit a shell’s environment variables on macOS or Linux. If your proxy is configured in .zshrc and you start VS Code from Spotlight, the extension host never sees it.

Why does a code editor panel need to reach the network before it renders? Because startup fetches account state. One log excerpt from the thread shows what the extension is calling even when the user has configured an API key rather than a ChatGPT login:

WARN codex_core_plugins::manager: failed to warm featured plugin ids cache
error=remote featured plugin request to
https://chatgpt.com/backend-api/plugins/featured?platform=codex
failed with status 401 Unauthorized

That request goes to chatgpt.com regardless of which provider you configured. If your network cannot reach it, initialization stalls at a point the old watchdog would eventually kill. If you are hitting 401s in the CLI rather than the panel, the Codex CLI 401 breakdown separates the three different root causes behind that status code.

You can test that specific path in one line. Run it from the same machine and the same network as the failing editor:

curl -s -o /dev/null -w "%{http_code} in %{time_total}s\n" \
  "https://chatgpt.com/backend-api/plugins/featured?platform=codex"

Read the result like this:

Tested unauthenticated from a normal connection, the endpoint returns 401 in about 100 ms with a 25-byte body of {"detail":"Unauthorized"}, which matches the response quoted in the extension logs above verbatim. The 401 in your log is not evidence of an auth bug. It is evidence the request completed. Silence is the failure mode to look for, not rejection.

Cause 3: Pending Account-Identity Requests

This is the one that survives every fix, and it has its own tracking issue: openai/codex#37521, open at the time of writing with labels for auth and connectivity.

The failure shape: an account identity request goes out and simply never resolves. No error, no timeout, no fallback to offline mode. Startup waits forever. Before 26.810.41047 the watchdog would eventually replace the panel with the resources error, which at least told you something had gone wrong. Now the panel just sits there.

There is no clean user-side fix. What has worked for some people:

1. Open the ChatGPT desktop app, sign in again, fully restart VS Code
2. Reload the window two or three times (Cmd/Ctrl+Shift+P → Developer: Reload Window)

Both are re-authentication in disguise, and neither is reliable. If reload cycling gets you a working panel, treat it as a workaround with a shelf life, not a fix.

Cause 4: Browser Service-Worker Cache

Specific to VS Code Web and code serve-web sessions accessed through a browser. The webview assets are cached by the browser’s service worker, and after an extension update the cached asset graph can reference files that no longer exist under the same names.

Symptoms that point here rather than elsewhere:

• Only reproduces in a browser tab, never in desktop VS Code on the same machine
• Survives Developer: Reload Window
• Multiple VS Code Web windows connected to the same server behave inconsistently

The fix is a hard cache bust on the browser side: clear site data for the VS Code Web origin, then reload. A normal refresh will not do it, because the service worker serves the stale graph before the network is consulted.

Cause 5: Positron and GitHub Copilot

Narrow but cleanly reproducible, reported on Positron 2026.08.0 (Code OSS 1.124.0) on Ubuntu 24.04. Codex works normally until GitHub Copilot authenticates as a language model provider. After Copilot is enabled and Positron restarts, Codex fails. Logging out of Copilot and restarting restores it.

This reproduces from a clean user profile, so it is not accumulated config damage. If you run both in Positron, that is your answer and no amount of Codex reinstalling will help.

Which Fixes Circulating Online Don’t Work?

Three of them, and the most popular one costs you your login in exchange for nothing.

Three suggestions spread widely in the GitHub thread and in the search results around it. All three are worth knowing about specifically so you can skip them.

Deleting ~/.codex/auth.json. The single most-repeated suggestion. It made intuitive sense because the extension does stall on auth-adjacent work, and the first person to post it reported success. But others tried it and got nothing, and one reported the error returned as soon as they changed workspaces. It costs you your session in exchange for a coin flip. The watchdog fired on a handshake timeout, and deleting a credentials file does not make a webview render faster.

Chasing the data:font/woff2 CSP warning. The original issue report included a console line showing Chrome’s CSP blocking an inline base64 font, and it reads like a smoking gun. It is not. The warning appears in windows that start perfectly well. Diagnostic work later in the thread confirmed it is not the blocker.

Patching startup.whenReady() out of the webview bundle. This one deserves more respect than the other two because the person who proposed it did real work and it did help people. But the mechanism was wrong, as shown by the actual line quoted earlier: N.startup == null is true in VS Code builds, so whenReady() is dead code there. The patch helped as a side effect of regenerating the asset graph. If you applied it, undo it after updating. Hand-edited bundles inside an extension directory get silently replaced on the next auto-update anyway, and if the edit corrupts a non-ASCII character on the way through, which happened to one PowerShell implementation via the Windows ANSI code page, you get a syntax error instead of a working panel.

Codex Extension Failure Timeline: The 26.803 Regression

Six days from first report to shipped fix, across six builds.

The issue is labelled windows-os, and the original report was Windows. But the thread collected confirmations on macOS, Debian 13, Ubuntu via Remote-SSH, WSL2, and VS Code Web in Firefox. If you dismissed this bug because you are not on Windows, that label misled you.

How to Roll Back to a Specific Version

If you need 26.727.40816 right now, do not use the Extensions panel. The gear menu’s “Install Another Version” path is what failed for the person who filed the original issue, with Error while downloading VSIX: Canceled. The CLI is more reliable and takes one line:

code --install-extension openai.chatgpt@26.727.40816 --force

Tested on macOS with VS Code 1.132.0. It resolves the platform-specific package for you and reports the installed version on success:

Installing extension 'openai.chatgpt' v26.727.40816...
Extension 'openai.chatgpt' v26.727.40816 was successfully installed.

Then turn off auto-update for this one extension, or the next background update undoes your rollback within the day. In the Extensions panel, right-click Codex and uncheck Auto Update.

To go forward again, install without a version suffix:

code --install-extension openai.chatgpt --force

Where the Logs Actually Live

The Codex.log file referenced throughout the GitHub thread is per-window and buried under a timestamped directory, which is why so many reporters posted screenshots of the panel instead of logs:

A new timestamped directory is created per VS Code session, so sort by modification time and take the newest. The faster route to the same content is the Output panel: Cmd/Ctrl+Shift+U, then pick Codex from the dropdown.

For failures that never reach the extension host at all, cause 4 in particular, the extension log will be empty of useful detail. Use Developer: Open Webview Developer Tools from the command palette, enable Preserve log in the Console tab, and reload the window. The first red error there is the one worth reading. That workflow is how the thread eventually isolated a renderer-side syntax error that no amount of Codex.log reading would have surfaced.

How Do You Keep Coding When the Editor Panel Won’t Start?

Use the CLI. It is a separate binary, and not one of the five causes above touches it.

Every cause above lives in the VS Code webview layer. None of them touch the agent itself, and this is the part most people miss while they are busy reinstalling an extension: the panel is a client, and it is not the only one.

Codex CLI is a separate binary with a separate process model:

codex --version
# codex-cli 0.147.0

If that responds, you have a working Codex regardless of what the sidebar is doing. The same is true in reverse, which is why the version table above is worth running before you start debugging anything: a broken panel and a broken CLI are almost never the same incident.

There is a second gap here that the timeline exposes. The fix reached the VS Code Marketplace on 2026-08-13, but OpenAI noted that Windows packages are not currently published to Open VSX, pending an unresolved package-size limit on the registry, an issue open since March 2026. Editors that pull from Open VSX rather than the Marketplace, which includes several VS Code forks, may still be serving Windows users a build from before the fix. If you are on such an editor and the version table shows 26.803.x with no update available, that is why.

Both gaps have the same shape: your access to a model is mediated by one vendor’s client, on one vendor’s release schedule, through one vendor’s registry. Because Codex CLI speaks OpenAI-compatible HTTP, pointing it at a different endpoint is two environment variables:

export OPENAI_BASE_URL=https://api.ofox.ai/v1
export OPENAI_API_KEY=your_key
codex

That keeps the terminal path working while the extension is down, and it is the same configuration whether the thing that broke was the extension, the registry, or a regional rollout. The custom model provider setup covers the config file equivalent if you would rather not use environment variables, and ofox exposes the current Codex-compatible models through one key if you want a fallback that does not depend on which build of a Chrome or VS Code plugin shipped this week.

How Do You Verify the Fix Actually Landed?

Check the version number, then grep the bundle if you want proof instead of a version number. Three checks, in order of how much they tell you.

Check the version. The table at the top of this page. Anything 26.810.x or later carries the fix.

Check the string. If you want to confirm the watchdog is gone in the build you have rather than trusting a version number, the error text lives in the extension host bundle:

grep -c "couldn't load its resources" \
  ~/.vscode/extensions/openai.chatgpt-*/out/extension.js

Expect one line per installed copy, in the form <path>:<count>. A count of 0 means that copy is clean. Any non-zero count is an affected build.

One thing that trips people up here: VS Code does not always remove the old directory when you update or uninstall, so this glob can match several versions at once and report on builds you are no longer running. Read the version out of the path rather than trusting a bare number. On a machine where a rollback and an update had both been tested, the command returns two lines:

/Users/you/.vscode/extensions/openai.chatgpt-26.810.41047/out/extension.js:0
/Users/you/.vscode/extensions/openai.chatgpt-26.727.40816-darwin-arm64/out/extension.js:0

Both are clean, for different reasons: one is post-fix, the other predates the watchdog entirely. Note also that packages installed from the Marketplace carry a platform suffix in the directory name while manually installed VSIX files do not, so the two forms sitting side by side is normal rather than a sign of a broken install.

Check the log. Open the Codex output channel after a cold start and look for the three renderer milestones listed in the diagnosis section. React root render requested, app routes mounted, ready provider mounted. All three present means the webview booted end to end, whatever else may be slow.

For the extension specifically, the VS Code Marketplace listing shows the current version and release date, and the version history there is the fastest way to check whether a build newer than the one you have exists for your platform. Note that the Marketplace serves platform-specific packages, so the newest version for win32-x64 and for darwin-arm64 can differ by hours.

What If It’s Not the Extension at All?

Two neighbouring failures look almost identical on screen and are not this bug.

Two neighbouring failures produce panic in the same direction and have nothing to do with this bug.

If Codex is not visible in your editor because it never installed, or because your shell cannot find the binary, that is a PATH and install problem, covered in codex: command not found. If the Codex desktop app on Windows fails with an app-server manifest error mentioning resourcesPath, that is a native-host registration problem and a genuinely different bug, covered in Codex failed to start the app server. The word “resources” appearing in both messages is a coincidence that has cost people hours.

And if your panel starts fine but your custom models are missing from the picker, nothing is broken in the startup path at all. That is a configuration problem in the desktop app.

References

• https://github.com/openai/codex/issues/37458
• https://github.com/openai/codex/issues/37521
• https://github.com/EclipseFdn/open-vsx.org/issues/8724
• https://marketplace.visualstudio.com/items?itemName=openai.chatgpt