# Codex extension fails to start: "The extension couldn't load its resources"

Regression in openai.chatgpt 26.803.41515: Codex panel fails to load resources

Summary

After updating to openai.chatgpt 26.803.41515, the Codex panel fails to start with:

Codex could not start. The extension couldn't load its resources.

Rolling back to openai.chatgpt 26.5730.61639 fixes the issue, so this appears to be a regression introduced in 26.803.41515.

Environment

• OS: Windows x64
• VSCode: 1.132.0 (commit df53daabb18cd157bdb08c7f01c34df936cf12f4)
• Broken version: openai.chatgpt 26.803.41515 (win32-x64)
• Working version: openai.chatgpt 26.5730.61639
• Extension update date: 2026-08-07

Steps to reproduce

1. Update Codex to version 26.803.41515.
2. Open VSCode and open the Codex sidebar or panel.
3. Wait about 30 seconds; the error "Codex couldn't load its resources." appears.

Console output (Developer Tools)

Key error lines:

index.html?id=...&extensionId=openai.chatgpt...
Loading the font 'data:font/woff2;base64,...' violates the following Content Security Policy directive: "font-src 'self' https://*.vscode-cdn.net". The action has been blocked.
...
Codex couldn't load its resources.

Troubleshooting already tried

• Developer: Reload Window
• Fully quit and restart VSCode
• Uninstall and reinstall the extension
• Cleared %APPDATA%\Code\Service Worker\CacheStorage and ScriptCache
• Rolled back to 26.5730.61639 by installing the VSIX directly: Codex works normally again

Additional analysis

From the extension source, initializeWebview sets a 30-second startup timeout for the webview and requires a ready message within that window. If VSCode's CSP blocks the data:font resource, the frontend may fail to initialize and trigger this error. Please confirm compatibility between 26.803.41515 and VSCode 1.132.0, and consider whether the webview's data:font should be served differently.

I can independently reproduce this issue on Windows.

Environment

• OS: Windows x64
• VS Code version: 1.132.0
• VS Code commit: df53daabb18cd157bdb08c7f01c34df936cf12f4
• Affected Codex extension: openai.chatgpt 26.803.41515

Behavior

The issue started immediately after the Codex extension was automatically updated on August 7, 2026.

Opening the Codex panel displays:

Codex could not start The extension couldn't load its resources.

The webview requests React rendering but does not send the expected ready message within approximately 30 seconds. The Codex log then reports:

Webview did not finish starting

Diagnostics performed

I performed the following checks:

• Reproduced the issue using a completely clean and isolated VS Code profile.
• Compared the installed extension directory with the signed VSIX package.
• All 4,516 files were present, and the core resource hashes matched.
• Clearing the normal VS Code and extension state did not resolve the issue.
• Similar network-related errors are also present in an older working version, so those errors do not appear to be the direct cause.
• A data:font CSP warning is present. For diagnostic purposes, I tested with the CSP restriction bypassed locally, but the webview still timed out.

This does not appear to be caused by an incomplete or corrupted extension installation.

The CSP warning may be relevant, but bypassing it did not resolve the startup timeout, so I cannot confirm CSP as the root cause.

This appears to be a regression in the Windows webview initialization or compatibility behavior introduced in version 26.803.41515.

Workaround

Downgrading to an earlier Codex extension version restores normal operation.

Related report

Another user reported the same two-line startup error here:

https://github.com/openai/codex/issues/3801#issuecomment-5217489064

Screenshot

<!-- Drag and drop the error screenshot below this line before submitting. -->

I also get this issue on my linux cloud platform

Hi I found out that theres a solution for this one!

I have the same problem, and this solution have solved it. And this problem may be failed by authentication so we just remove the authen file btw ^^

• First, get into the .codex folder which has been placed in your user's folder, for example "C:\Users\<your_account>\.codex"
• Then, remove the "auth.json" file, and restart your ide and it solved!!

Hope that would help you guys!

+1

I'm getting this as well and the previous comment about deleting the auth.json doesn't fix it

26.803.41515 release can help anyone affected get working again until the latest version is fixed.

Environment: Windows (VSCode) → Remote-SSH → Ubuntu 22.04
Broken: 26.803.41515 | Working: 26.727.40816

Logs:

text
[error] Request failed error={"code":-32603,"message":"No such file or directory (os error 2)"} method=fs/readFile
[error] [CodexWebviewProvider] Webview did not finish starting extensionVersion=26.803.41515 role=sidebar
Workaround: Downgrade to 26.727.40816 fixes it.

Same regression on Remote-SSH as Windows native. The fs/readFile error suggests local file init fails before network.After downgrading, the fs/readFile error still appears but does NOT block Codex startup anymore. The fatal issue is specifically the webview timeout in 26.803.41515. This error seems to be a separate non-fatal issue (possibly codex-core trying to read a missing plugin file). The real regression in 26.803.41515 is the webview initialization timeout.

我发现解决办法是开启VPN代理就行，感觉是codex请求国外某些资源

## Description The Codex panel fails to start after opening VSCode and shows: > Codex could not start. The extension couldn't load its resources. ## Environment OS: Windows x64 VSCode: 1.132.0 (commit df53daabb18cd157bdb08c7f01c34df936cf12f4) Extension: openai.chatgpt 26.803.41515 (win32-x64) Extension installed/updated: 2026-08-07 ## Steps to reproduce 1. Open VSCode. 2. Open the Codex sidebar or panel. 3. Wait about 30 seconds; the error "Codex couldn't load its resources." appears. ## Console output (Developer Tools) Key error lines: `` index.html?id=...&extensionId=openai.chatgpt... Loading the font 'data:font/woff2;base64,...' violates the following Content Security Policy directive: "font-src 'self' https://*.vscode-cdn.net". The action has been blocked. ... Codex couldn't load its resources. ` ## Troubleshooting already tried * Developer: Reload Window * Fully quit and restart VSCode * Uninstall and reinstall the Codex extension * Cleared %APPDATA%\Code\Service Worker\CacheStorage and ScriptCache * Tried to roll back the extension version, but "Install Another Version..." failed with "Error while downloading VSIX: Canceled" ## Additional analysis From the extension source, initializeWebview sets a 30-second startup timeout for the webview and requires a ready message within that window. If VSCode's CSP blocks the data:font resource, the frontend may fail to initialize and trigger this error. Please confirm compatibility between 26.803.41515 and VSCode 1.132.0, and consider whether the webview's data:font` should be served differently.

Fixed

i Faced the same error but i was able to fix it by doing these 1. cmd shift X 2. scroll to codex and click gear icons on codex 3. click install previouse version 4. select the second version on the list

i Faced the same error but i was able to fix it by doing these

1. cmd shift X 2. scroll to codex and click gear icons on codex 3. click install previouse version 4. select the second version on the list

I also have the same issue

i return to version about 1 month before and solve the problem

我发现解决办法是开启VPN代理就行，感觉是codex请求国外某些资源

+1

Same issue for me as well on mac. When i switched CODEX to "Version 26.5803.41515", it started working

Please treat this issue seriously and fix it as soon as possible; it is making the VS Code remote development environment extremely unstable.

I can reproduce a very similar issue on Windows 11 with exactly the same Codex Desktop package version: OpenAI.Codex 26.803.5235.0.

The app became progressively slower and eventually the UI crashed / showed “ChatGPT was unexpectedly terminated”.

Immediately before terminating the processes, I measured:

codex.exe: 13.69 GB Working Set
second codex.exe: 3.67 GB Working Set

After terminating ChatGPT/Codex, I installed and tested the standalone codex-cli 0.147.0 on the same Windows machine using a fresh isolated CODEX_HOME.

The CLI started successfully and its codex.exe process used only approximately 0.13 GB Working Set during the smoke test.

So on the same machine I observed roughly:

Codex Desktop/app-server: 13.69 GB + 3.67 GB
standalone Codex CLI 0.147.0: 0.13 GB

I have multiple Codex projects/threads in the Desktop app. I have not yet verified whether my affected histories contain the same large inline-image/fork pattern described in this issue.

I can provide additional redacted process measurements or logs if useful.

Hi I found out that theres a solution for this one! I have the same problem, and this solution have solved it. And this problem may be failed by authentication so we just remove the authen file btw ^^ First, get into the .codex folder which has been placed in your user's folder, for example "C:\Users<your_account>.codex" Then, remove the "auth.json" file, and restart your ide and it solved!! Hope that would help you guys!

This is a temporary solution. If you closed changed the workspace, the issue goes back.

Please treat this issue seriously and fix it as soon as possible; it is making the VS Code remote development environment extremely unstable.

Codex could not start
The extension couldn't load its resources.

[error] [CodexWebviewProvider] Webview did not finish starting extensionVersion=26.803.41515 role=sidebar
[error] Statsig: error while bootstrapping post-login client attemptNumber=1 error={}

same issue

Same issue on Debian 13 since last update of extension. Downgrade to older version helped.

Workaround that fixes the root cause without downgrading

I hit this exact bug on 26.803.41515 (Windows / VS Code). Downgrading works around it, but here's a direct fix if you want to stay on the current version.

Root cause: the extension host starts a ~30s timer and waits for the webview to send a {type:"ready"} handshake. In this version the webview startup deadlocks — app-main-*.js gates rendering behind N.startup.whenReady(), which never resolves on some machines. Codex.log then records Webview did not finish starting and the panel is replaced with the error page. The "couldn't load its resources" text is misleading: the assets actually load fine.

Fix (edit the webview bundle, back up first):

1. Go to <extensions-dir>/openai.chatgpt-26.803.41515*/webview/assets/
2. Open app-main-*.js (hash-named, e.g. app-main-BpHShvzH.js).
3. Find this line (appears exactly once):

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

1. Replace it with:

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

d is the webview→host message channel — the same d.dispatchMessage(...) used elsewhere in the file.

1. Save, then fully restart VS Code.

Result: panel loads normally; Codex.log no longer shows Webview did not finish starting.

Caveats: version-specific — re-apply after the extension auto-updates. Ideally OpenAI fixes the handshake in the extension itself.

Thanks everyone for the help! It's all fixed now. Appreciate it!

This might sound like a slightly dumb workaround 😅, but it actually fixed the issue for me.

If you have the ChatGPT desktop app installed:

1- Open the ChatGPT desktop app.
2- Log in again to your account.
3- Fully restart your IDE / VS Code.
4- Open Codex again.

For some reason, Codex started working normally after doing this.

It might be related to authentication/session state, especially since some of the other workarounds here also seem to involve re-authentication.

Not sure if this will work for everyone, but worth trying before downgrading or modifying extension files.

Practical testing shows that installing an older version of the Codex plugin in VS Code resolves this issue. The version I switched to is v26.803.41515.

Workaround that fixes the root cause without downgrading I hit this exact bug on 26.803.41515 (Windows / VS Code). Downgrading works around it, but here's a direct fix if you want to stay on the current version. Root cause: the extension host starts a ~30s timer and waits for the webview to send a {type:"ready"} handshake. In this version the webview startup deadlocks — app-main-*.js gates rendering behind N.startup.whenReady(), which never resolves on some machines. Codex.log then records Webview did not finish starting and the panel is replaced with the error page. The "couldn't load its resources" text is misleading: the assets actually load fine. Fix (edit the webview bundle, back up first): 1. Go to <extensions-dir>/openai.chatgpt-26.803.41515*/webview/assets/ 2. Open app-main-*.js (hash-named, e.g. app-main-BpHShvzH.js). 3. Find this line (appears exactly once): let e=G||K||N.startup==null?void 0:Promise.resolve(N.startup.whenReady()); 4. Replace it with: d.dispatchMessage(ready,{});let e=void 0; d is the webview→host message channel — the same d.dispatchMessage(...) used elsewhere in the file. 5. Save, then fully restart VS Code. Result: panel loads normally; Codex.log no longer shows Webview did not finish starting. Caveats: version-specific — re-apply after the extension auto-updates. Ideally OpenAI fixes the handshake in the extension itself.

I tried every method above, this is the only way worked

@etraut-openai I reproduced this and found that the timeout is caused by the webview readiness handshake being coupled to business initialization. Could you route this to the VS Code extension webview owner if needed?

The public openai/codex repository and the other public repositories under the OpenAI organization do not appear to contain the extension webview source, so I could not prepare a source PR. I inspected the shipped bundles from both 26.803.41515 (release) and 26.5803.41515 (pre-release) instead.

The existing workaround that bypasses N.startup.whenReady() identifies the 30-second handshake, but that does not appear to be the blocking branch in the VS Code build: the VS Code service object does not register startup, so the optional startup.whenReady() expression evaluates to undefined.

The readiness reporter that dispatches {type: "ready"} is nested below the application's business provider/route tree. A first clean-profile experiment moved it outside the nearest route Suspense boundary and appeared to work, but an established profile proved that this was not high enough: an ancestor provider can still suspend while Statsig/auth/data initialization is pending. The account lookup itself succeeded (authenticatedAccountPresent=true), so deleting auth state is not required.

The reliable fix was to dispatch the host readiness message immediately after the React runtime and webview-to-host message channel were initialized, before rendering the business provider/route tree. The existing route-mounted reporter was retained for diagnostics but no longer dispatches a second ready message.

Validation from two normal VS Code Insiders windows using the established profile:

• Window 1: React root requested at 11:02:23.919, runtime ready at 11:02:23.921, routes mounted at 11:02:50.542 (performance.now() reported 30,444 ms).
• Window 2: React root requested at 11:03:52.828, runtime ready at 11:03:52.829, routes mounted at 11:04:08.875 (performance.now() reported 20,898 ms).
• Neither window emitted Webview did not finish starting; both panels became usable.

Suggested source-level ordering:

initializeWebviewRuntimeAndHostChannel();
notifyHostReady();
root.render(<App />);

ready should mean that the webview runtime is alive and can communicate with the extension host. Route/auth/feature-flag/data readiness should remain separately observable and may show its own loading or error state without allowing the host's resource watchdog to replace the entire webview.

This is happening for me on macOS as well, version 26.803.41515. restarting VS code didn't help, restarting the machine also didn't help. downgrading to the previous version from 2 weeks ago fixed it.

I use the command codex . and then refresh the page with Ctrl+Shift+P followed by Developer: Reload Window. After repeating this two or three times, it usually works. I’m not sure if it’s stable, and I’m using Debian 13 x64.

code --version
code --list-extensions --show-versions | grep -i openai

1.132.0

openai.chatgpt@26.803.41515

@shipiyouniao Really solid diagnostic work here - appreciate that you didn't stop at "found a workaround" but actually traced why the previous patch worked by accident (the startup service object not being registered, so the expression just evaluates to undefined). The performance.now() timestamps from both test windows make the root cause hard to argue with.

The proposed fix is the right shape too: decoupling "webview runtime is alive" from "app is business-ready" is a real architectural fix, not another bypass, and keeping the route-mounted reporter for diagnostics while removing the duplicate ready dispatch is a thoughtful touch. Hope this gets picked up and shipped.

I can reproduce this on the current affected build in a VS Code Web / code serve-web setup.

Environment

• Codex extension: openai.chatgpt 26.803.41515 (linux-x64)
• VS Code Web: 1.132.0, commit df53daabb18cd157bdb08c7f01c34df936cf12f4
• Remote host: Linux x86_64
• Browser client: Firefox 153.0.3 on Windows

Observed startup sequence

The Codex app-server is healthy and completes initialization. In failed windows, the extension log contains:

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

The failed run has none of these renderer milestones:

React root render requested
app routes mounted
ready provider mounted

This is not an authentication failure. The static error page is the extension host's startup watchdog replacing a webview that did not send ready.

A/B result

The shipped bundle still contains the Vite helper that creates a modulepreload link for each non-CSS dependency.

I changed only that helper to skip non-CSS preload links while retaining CSS preload handling, as described in #34103. No auth, configuration, project, or task data changed.

After the change and a reload of the established Firefox session:

React root render requested
app routes mounted after 22552ms
ready provider mounted

The panel became usable and the active task resumed normally. A clean Chromium control loaded the same patched bundle with 26 successful resource responses, zero failed resources, and mounted routes after 11787 ms.

This indicates that the blocked data:font CSP warning is not the root cause for this reproduction. The effective change does not alter fonts or CSP.

Firefox overlap

A separate clean-profile Firefox control failed earlier in the VS Code webview service-worker layer: the worker was absent, and the Codex application bundle did not begin loading. Before the preload patch, synthetic vscode-resource.vscode-cdn.net requests could also escape to normal network resolution and fail.

Two relevant Firefox bugs are:

• Mozilla Bug 2029029: synthetic vscode-remote+...vscode-resource.vscode-cdn.net resources are not consistently intercepted by the service worker in code-server-style setups.
• Mozilla Bug 2052949: incorrect Firefox modulepreload error behavior; fixed for Firefox 155.

The first-load Firefox service-worker failure and the Codex preload storm are separate but can produce the same user-facing error.

Suggested upstream changes

1. Drop JS modulepreload hints for the VS Code webview target, or load them in bounded batches.
2. Keep CSS preload handling.
3. Send the host ready signal after the webview runtime and host channel initialize. Do not couple the watchdog to route, auth, feature-flag, or data readiness.
4. Report the failed startup stage. The current "couldn't load its resources" message conflates resource transport, service-worker, and business-initialization failures.

This current-version result extends the root-cause evidence in #34103 and helps distinguish it from the separate readiness-ordering analysis already posted in this issue.

I can reproduce the same issue on VS Code 1.132.0 with Remote

• WSL2 (Linux x64). The affected extension version is 26.803.61601. Downgrading to 26.5707.41301 restores normal operation.

Hi everyone! My name is Alex and I just joined the Codex team working with @etraut-openai.

Thanks to everybody who reported this issue and provided logs and analysis. We believe a recent change exposed an existing bug that was previously masked, and we're working on a fix. I'll update this issue when I have more information and a timeline for release.

我更新26.803.61601版本chatgpt插件后也出现了
vscode日志里说是连接不上chatgpt.com，但是我用的是第三方apikey，它本来不应该访问chatgpt官网去获取登录状态

"C:\Users\PC\AppData\Roaming\Code\logs\20260811T112728\window1\exthost\openai.chatgpt\Codex.log"
2026-08-11 11:16:52.386 [error] [CodexMcpConnection] cli: message="2026-08-11T03:16:51.656744Z 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: {\"detail\":\"Unauthorized\"}\n

If the above methods don't solve the problem, check if the "http.proxySupport" parameter in your vscode setting.json file is set to "off". In my case, this parameter might have been changed when I was using the agent to troubleshoot network issues. Setting it to "on" will allow the plugin to use the system proxy (e.g., Clash's port 7890), and the problem will no longer occur.

Follow-up: 26.803.61601 may require a full asset-graph cache bust in Firefox / VS Code Web

This updates my earlier Firefox / VS Code Web reproduction in this issue.

Environment

• Codex extension: openai.chatgpt 26.803.61601 (linux-x64)
• VS Code Web: 1.132.0, commit df53daabb18cd157bdb08c7f01c34df936cf12f4
• Browser: Firefox on Windows
• Extension host: Linux x86_64
• Multiple VS Code Web windows connected to the same server

No authentication, account, project, or task data was changed during this test.

New result

The CSS-only preload workaround from #34103 was still necessary, but it was not sufficient after the extension update when Firefox had already used the VS Code webview service-worker cache.

The backend remained healthy:

Initialize received id=1

The failed webview never reached the first renderer milestone and timed out after 30 seconds:

[CodexWebviewProvider] Webview did not finish starting extensionVersion=26.803.61601 role=sidebar

Firefox's Disable HTTP Cache option does not affect Service Workers or the Cache API. VS Code's webview service worker also explicitly uses a versioned CacheStorage cache, calls cache.match(event.request), and writes resource responses with cache.put(...). Relevant source:

• https://firefox-source-docs.mozilla.org/devtools-user/settings/index.html
• https://github.com/microsoft/vscode/blob/df53daabb18cd157bdb08c7f01c34df936cf12f4/src/vs/workbench/contrib/webview/browser/pre/service-worker.js

Effective local recovery workaround

The working recovery used all of these steps:

1. Keep CSS preload handling.
2. Skip non-CSS modulepreload injection in the generated preload helper.
3. Remove static <link rel="modulepreload"> entries from webview/index.html.
4. Copy or reflink the entire webview/assets tree to a new unique directory, for example:

``text
webview/assets-cache-bust-<nonce>/
``

1. Change the entry script and stylesheet URLs in webview/index.html from ./assets/... to the new directory.
2. Reload affected VS Code Web windows sequentially.

Copying only the main entry chunk is not sufficient. Relative and dynamic imports must also resolve under the new directory. Otherwise, they reuse the old resource URLs and can hit the existing service-worker cache entries.

Conceptually, the index change is:

- <script type="module" src="./assets/index-<hash>.js"></script>
- <link rel="stylesheet" href="./assets/app-initial-<hash>.css">
+ <script type="module" src="./assets-cache-bust-<nonce>/index-<hash>.js"></script>
+ <link rel="stylesheet" href="./assets-cache-bust-<nonce>/app-initial-<hash>.css">

The generated preload helper also needs the existing CSS detection followed by an early return for non-CSS dependencies:

if (!isCssDependency) return;

This is an extension-local workaround. An extension update overwrites it.

Validation

Two affected windows were first reloaded at the same time:

• one mounted successfully;
• one still hit the 30-second watchdog.

The failed window was then reloaded by itself. Both windows completed startup:

React root render requested
Features enabled
app routes mounted after 18992ms
ready provider mounted

React root render requested
Features enabled
app routes mounted after 6807ms
ready provider mounted

Both extension hosts remained active, and no new Webview did not finish starting event appeared.

This is consistent with two overlapping problems:

1. unbounded JS modulepreload pressure;
2. stale or partial resource graphs retained by the VS Code webview service-worker cache.

Suggested product changes

1. Do not emit JS modulepreload hints for the VS Code webview target, or load them in bounded batches.
2. Include the extension build or asset manifest hash in every webview resource URL.
3. Rotate or invalidate the webview resource cache after an extension update and after a failed startup.
4. Make Retry create a fresh resource URL namespace instead of reusing the same cached graph.
5. Keep the host ready signal independent from route, auth, feature-flag, and data readiness.
6. Report the startup stage that failed instead of using one generic resource error.

Disabling Service Workers globally is not a viable workaround because VS Code webviews depend on them.

Also meet the problem with 26.803.61601

Actually this problem is a network accessing issue for me. Quick evaluate by starting vscode in bash shell with https proxy set.

export https_proxy=http://127.0.0.1:9001
code

Starting like this, codex plugin sidebar opens fluently.

It also happens with Positron and Ubuntu:
Description
The OpenAI Codex extension fails to load its resources in Positron after GitHub Copilot is authenticated as a language model provider.

The issue is reproducible with a clean Positron user profile. Codex works normally until GitHub Copilot is authenticated. After enabling GitHub Copilot and restarting Positron, Codex fails with the following message:

Codex could not start
The extension couldn't load its resources.

Logging out of GitHub Copilot and restarting Positron restores normal Codex functionality.

Environment
Positron

Positron Version: 2026.08.0 build 331
Code - OSS Version: 1.124.0
Commit: a3a370d4187484ce962794408c76dab702978eaf
Date: 2026-08-05T17:02:37-07:00
Runtime

Electron: 42.2.0
Chromium: 148.0.7778.97
Node.js: 24.15.0
V8: 14.8.178.14-electron.0
Operating system

Ubuntu 24.04 LTS
Linux x64 6.8.0-137-generic
Codex

OpenAI Codex extension version: 26.803.41515
Release version (not Pre-Release)
GitHub Copilot

Configured through Positron's native language model provider authentication.
Positron was launched with:

positron --extensions-dir "$HOME/.positron/extensions"
Steps to reproduce
Start with a clean Positron user profile.
Install the Release version of the OpenAI Codex extension (26.803.41515).
Start Positron.
Open Codex and verify that it loads and works normally.
Authenticate GitHub Copilot as a language model provider in Positron.
Restart Positron.
Open Codex.
Actual behavior
Codex no longer loads. The Codex panel displays:

Codex could not start
The extension couldn't load its resources.

Expected behavior
Codex and GitHub Copilot should be able to operate simultaneously. In particular, I would like to use Codex together with GitHub Copilot inline code completions.

The problem got solved when downgrading Codex to version 26.527.60818

For Windows users whose logs show the 30-second webview readiness timeout (Webview did not finish starting), I published a small temporary workaround here:

https://github.com/shipiyouniao/codex-webview-fix

It contains PowerShell apply and restore scripts only; no modified extension JavaScript is redistributed. The script discovers the active openai.chatgpt installation, validates the expected bundle structure, creates a backup, and fails before writing if the installed version no longer matches the validated pattern.

I validated apply, repeated apply (idempotency), and restore against openai.chatgpt 26.803.61601 on Windows. This is intentionally a narrow workaround for the readiness timeout. It does not address proxy failures or VS Code Web service-worker cache issues that can produce the same generic error message. An upstream release remains the proper fix.

Codex VS Code Webview startup failure — verified regression and downgrade workaround

Recommended destination: add the English report below as a comment to
openai/codex#37458, rather than opening a duplicate issue.

GitHub comment (English)

Environment

• OS: Windows x64
• VS Code: 1.132.0 / 1.132.1
• Failing Codex extension: openai.chatgpt 26.803.41515
• Also observed as slow/unreliable with: 26.803.61601
• Working Codex extension: openai.chatgpt 26.727.40816
• Authentication mode: API key only
• Custom API-compatible provider: configured (URL and key redacted)
• ChatGPT session tokens: not present
• VS Code http.proxy: not configured during the failing reproduction
• HTTP_PROXY / HTTPS_PROXY: not set in the extension-host environment

Symptom

Opening the Codex sidebar eventually displays:

Codex could not start
The extension couldn't load its resources.

The failure occurs about 30 seconds after the webview begins rendering.

Relevant log sequence

[CodexMcpConnection] Initialize received id=1
[statsig-refresh-diagnostics] React root render requested windowType=extension
Error fetching error="TypeError: fetch failed" url=https://ab.chatgpt.com/v1/initialize?...
[CodexWebviewProvider] Webview did not finish starting extensionVersion=26.803.41515 role=sidebar

The failing startup never reaches:

[startup][renderer] app routes mounted
[statsig-refresh-diagnostics] ready provider mounted

There are also warnings such as:

chatgpt authentication required for remote plugin catalog; api key auth is not supported

However, these plugin-catalog warnings do not appear to be the direct cause:

• the bundled app-server initializes successfully;
• the webview JavaScript executes far enough to request the React root render;
• the same warnings were present in a session where the webview later mounted successfully;
• the machine uses API-key authentication and has no ChatGPT session or refresh token;
• ordinary model requests use the configured API-compatible provider.

Checks performed

The following potential causes were checked:

1. Missing or locked extension resources

• package.json, out/extension.js, and webview/index.html were readable with exclusive file access.
• All JavaScript and CSS assets referenced by webview/index.html existed.
• No relevant ENOENT, EACCES, EPERM, or EBUSY error appeared in the Codex log.

1. Extension activation/app-server failure

• The extension activated normally.
• The bundled Codex app-server spawned and returned Initialize received id=1.

1. Static webview execution failure

• React root render requested proves that the packaged webview code was loaded and executed.

1. ChatGPT login/session refresh

• The local authentication state contained an API key only, with no ChatGPT tokens or refresh token.
• Removing or changing the company API-key configuration was not required for recovery.

1. Local timeout patch

• Extending the host watchdog from 30 seconds to 120 seconds was not reliable.
• In some runs, a newer build mounted after more than 30 seconds, but the delay was variable.
• This confirms that changing the outer watchdog is only a workaround and does not resolve the blocked startup dependency.

A/B result

With the same machine, VS Code installation, user profile, Codex configuration, API key, and network:

| Extension version | Result |
| --- | --- |
| 26.803.41515 | Fails consistently with the 30-second webview readiness error |
| 26.803.61601 | Slow/unreliable; may exceed the 30-second watchdog |
| 26.727.40816 | Starts successfully |

Downgrading through an official Windows x64 VSIX immediately restored the Codex UI. No changes were made to the API endpoint, API key, or auth.json.

Additional observation

During one failing VS Code session, another unrelated extension also reported that its webview never became ready. This suggests that VS Code/Electron webview scheduling, cache state, or network behavior may amplify the Codex regression. It does not explain the version-specific A/B result by itself.

The current Codex startup path appears to couple the ready signal to network/account/feature initialization. A request that remains pending can therefore prevent routes from mounting until the independent 30-second host watchdog replaces the page with the generic resource error.

Expected behavior

• The basic local/API-key Codex UI should mount without requiring ChatGPT account or plugin-catalog access.
• Network-backed account, plugin, and feature-flag requests should have bounded deadlines shorter than the webview watchdog.
• A timeout should enter a degraded/offline state instead of blocking the ready handshake.
• The error UI should identify the failed startup stage instead of reporting that static resources could not load.

Confirmed workaround

Downgrade and pin the extension to:

openai.chatgpt 26.727.40816 (win32-x64)

Then fully exit all VS Code windows and restart VS Code. Developer: Reload Window alone may continue using the previous extension-host state.

中文排障摘要

最终结论

这次故障不是资源文件被占用，也没有证据表明是公司账号多人登录导致。直接原因是 Webview 在 30 秒内没有发送 ready；26.803.41515 存在版本相关回归，网络请求悬挂、缓存或 Webview 状态可能进一步放大问题。

已确认事实

• Codex 扩展进程正常激活。
• Codex app-server 正常启动并完成初始化。
• Webview 静态资源已经执行到 React root render。
• 当前认证是 API Key 模式，没有 ChatGPT 登录令牌或刷新令牌。
• chatgpt.com 插件目录认证警告属于可选远程功能，不等于模型中转认证失败。
• 延长 30 秒超时只能掩盖问题，且会被插件更新覆盖。
• 在相同配置和网络下，回退至 26.727.40816 后恢复正常。

本机最终状态

• 已安装并固定：openai.chatgpt 26.727.40816
• 插件入口保持官方原始值：./out/extension.js
• 未保留 extension-timeout-wrapper.js
• 未修改公司中转地址、API Key 或 auth.json
• 官方 Windows x64 VSIX 已保存在当前目录，可用于离线重装

相关上游 Issue

• 主问题：openai/codex#37458
• 未设超时的账户请求导致启动阻塞：openai/codex#37521
• 慢代理触发 30 秒 Webview watchdog：openai/codex#38088
• 26.803.41515 回归报告（已合并到主问题）：openai/codex#37543

目前我不敢更新了2026-08-13

• 这让我无法使用新的功能 GPT5.6 的 /fast模式

@FreeCodeCampXYG
Try the fix script I posted above.
I'll update it as soon as possible if the official codex version updates cause the script to become invalid, until the issue is resolved.

试试看上面我发的修复脚本。
在官方解决问题以前，后面Codex版本更新如果导致脚本失效我也会第一时间更新脚本。

@FreeCodeCampXYG Try the fix script I posted above. I'll update it as soon as possible if the official codex version updates cause the script to become invalid, until the issue is resolved. 试试看上面我发的修复脚本。 在官方解决问题以前，后面Codex版本更新如果导致脚本失效我也会第一时间更新脚本。

我试了还是不行，然后我按照lvazdela
14h ago他说的 ，切换到version 26.527.60818版本，重启vs，搞定

> @FreeCodeCampXYG Try the fix script I posted above. I'll update it as soon as possible if the official codex version updates cause the script to become invalid, until the issue is resolved. > 试试看上面我发的修复脚本。 在官方解决问题以前，后面Codex版本更新如果导致脚本失效我也会第一时间更新脚本。 我试了还是不行，然后我按照lvazdela 14h ago他说的 ，切换到version 26.527.60818版本，重启vs，搞定

其实是因为这个问题只是执行表象，底层涉及很多根因。

我的修复脚本会把发送 ready 的时机提前到 React root render requested 附近。如果 Webview 在执行到这里之前就已经失败，例如卡在 module preload、静态资源加载或缓存阶段，那么这个补丁确实不会生效。

另外，脚本只能避免宿主因为 30 秒内没有收到 ready 而替换 Webview，不能修复代理、认证、provider 或网络请求本身的问题。前面的报告中也出现过 ab.chatgpt.com 请求失败、自定义 API provider、代理配置和 service-worker 缓存等不同情况。

如果你愿意继续帮忙定位，而不只是暂时通过降级恢复使用，可以把下面的信息发给我。我可以据此判断你的情况是否适合纳入脚本：

• Apply-CodexWebviewReadinessFix.ps1 的完整输出
• Codex 插件版本（当然我猜你当时用的应该是最新的）
• 然后在 vsc 里按 Ctrl + Shift + P，搜索并执行Developer: Open Logs Folder，找到最新的window*\exthost\openai.chatgpt\Codex.log，在 log 文件里搜索并发我对应位置附近的文本：
• React root render requested
• [startup][renderer] webview runtime ready（这个是我加的）
• Webview did not finish starting

发送日志前，请务必先删除 API Key、Token、自定义服务地址以及其他敏感信息。

> > @FreeCodeCampXYG Try the fix script I posted above. I'll update it as soon as possible if the official codex version updates cause the script to become invalid, until the issue is resolved. > > 试试看上面我发的修复脚本。 在官方解决问题以前，后面Codex版本更新如果导致脚本失效我也会第一时间更新脚本。 > > > 我试了还是不行，然后我按照lvazdela 14h ago他说的 ，切换到version 26.527.60818版本，重启vs，搞定 其实是因为这个问题只是执行表象，底层涉及很多根因。 我的修复脚本会把发送 ready 的时机提前到 React root render requested 附近。如果 Webview 在执行到这里之前就已经失败，例如卡在 module preload、静态资源加载或缓存阶段，那么这个补丁确实不会生效。 另外，脚本只能避免宿主因为 30 秒内没有收到 ready 而替换 Webview，不能修复代理、认证、provider 或网络请求本身的问题。前面的报告中也出现过 ab.chatgpt.com 请求失败、自定义 API provider、代理配置和 service-worker 缓存等不同情况。 如果你愿意继续帮忙定位，而不只是暂时通过降级恢复使用，可以把下面的信息发给我。我可以据此判断你的情况是否适合纳入脚本： Apply-CodexWebviewReadinessFix.ps1 的完整输出 Codex 插件版本（当然我猜你当时用的应该是最新的） 然后在 vsc 里按 Ctrl + Shift + P，搜索并执行Developer: Open Logs Folder，找到最新的window*\exthost\openai.chatgpt\Codex.log，在 log 文件里搜索并发我对应位置附近的文本： React root render requested [startup][renderer] webview runtime ready（这个是我加的） Webview did not finish starting 发送日志前，请务必先删除 API Key、Token、自定义服务地址以及其他敏感信息。

Feedback for codex-webview-fix

Tested repository commit:

4df38a21f9dcb2fcf6372d4362127521e9393d71

Environment

OS: Windows x64
VS Code: 1.132.1
Codex extension: openai.chatgpt 26.803.61601
Authentication: API key mode (key and provider URL redacted)
VS Code http.proxy: not configured
HTTP_PROXY / HTTPS_PROXY / ALL_PROXY: not set
Windows WinHTTP proxy: direct
Windows user proxy: disabled

The same machine works after downgrading to openai.chatgpt 26.727.40816 without changing authentication or provider configuration.

Apply script output

Patched openai.chatgpt 26.803.61601
Extension: C:\Users\xiaoy\.vscode\extensions\openai.chatgpt-26.803.61601
Backup: C:\Users\xiaoy\AppData\Local\CodexWebviewReadinessFix\backups\26.803.61601-20260813-150539-622-9359d08e
Restart VS Code or run Developer: Reload Window.

Before applying it to the installed extension, I also tested the script against an isolated extraction of the official 26.803.61601 Windows x64 VSIX:

First apply: succeeded
Second apply: reported Already patched
Restore: succeeded
Both restored bundle SHA-256 hashes matched the original files

Result

After fully restarting VS Code, the sidebar still displayed:

Codex could not start
The extension couldn't load its resources.

Redacted Codex.log excerpt

Log file:

%APPDATA%\Code\logs\20260813T150631\window1\exthost\openai.chatgpt\Codex.log

Relevant content:

2026-08-13 15:06:34.073 [info] Activating Codex extension
2026-08-13 15:06:34.073 [info] [CodexMcpConnection] Spawning codex app-server
2026-08-13 15:06:34.073 [warning] [IpcClient] Received broadcast but no handler is configured method=client-status-changed
2026-08-13 15:06:34.073 [warning] [IpcClient] Received broadcast but no handler is configured method=thread-stream-following-changed
2026-08-13 15:06:34.073 [warning] [CodexMcpConnection] cli: message="remote installed plugin bundle sync failed: ChatGPT authentication required for remote plugin catalog; API key auth is not supported"
2026-08-13 15:06:34.073 [info] [CodexMcpConnection] Initialize received id=1
2026-08-13 15:06:42.844 [warning] [CodexMcpConnection] cli: message="failed to warm featured plugin ids cache: request to the ChatGPT featured-plugin endpoint failed"
2026-08-13 15:07:04.077 [error] [CodexWebviewProvider] Webview did not finish starting extensionVersion=26.803.61601 role=sidebar

Search results in this failed startup:

React root render requested: NOT PRESENT
[startup][renderer] webview runtime ready: NOT PRESENT
Webview did not finish starting: PRESENT
app routes mounted: NOT PRESENT
ready provider mounted: NOT PRESENT

No API key, token, custom provider URL, or request query string is included above.

Additional local checks

The patch was applied to the expected bundle:

webview/assets/app-main-DOD1T6et.js

The bundle contains the inserted marker and early ready dispatch. However, webview/index.html does not load this file directly. The startup graph is:

webview/index.html
  -> four static modulepreload links
  -> assets/index-BEwQuALC.js
  -> dynamic import of assets/app-main-DOD1T6et.js
  -> React root render requested
  -> patched runtime-ready marker and ready dispatch

The failure therefore occurs before execution reaches the patched app-main bundle.

Checks performed:

• webview/index.html exists and matches the official VSIX.
• index-BEwQuALC.js and all four statically preloaded dependencies exist.
• The entry bundle and dependencies pass node --check.
• The installed webview contains 4,456 asset files, matching the official VSIX.
• Apart from the two files intentionally changed by the script, the checked entry/preload files have the same SHA-256 hashes as the official VSIX.
• No matching module-preload, Service Worker, CSP, or failed-resource error was written to the normal VS Code log files. The Webview developer console may contain additional evidence that is not forwarded to Codex.log.

Interpretation

This case appears to be outside the current script's patch point. It is consistent with failure or stalling during the Webview entry/module-preload/resource-cache phase, before app-main executes. The downgrade A/B result still indicates a Codex extension version regression or a version-specific interaction with the VS Code Webview resource pipeline.

Thanks for the detailed evidence. It confirms that your failure occurs before app-main executes, so I added an explicit asset-graph fallback in aebe033.

After reinstalling or upgrading back to openai.chatgpt 26.803.61601, fully close every VS Code window and run:

powershell -ExecutionPolicy Bypass -File .\Apply-CodexWebviewReadinessFix.ps1 `
  -ResetAssetGraph

This mode copies the complete asset tree to a new URL namespace, removes static JavaScript modulepreload links, keeps CSS preloading, and applies the readiness patch inside the isolated tree. It creates a manifest-backed backup, and Restore-CodexWebviewReadinessFix.ps1 restores index.html and removes the generated asset directory.

I validated the following against the official 26.803.61601 Windows bundle:

• all 4,456 assets are copied;
• the entry preload list contains CSS only;
• the generated entry passes node --check;
• repeated fallback application is idempotent;
• rollback restores the original index and deletes the generated tree;
• applying the normal patch first and the fallback second supports two-level rollback.

Could you try this fallback on the machine that produced the report? The most useful result is whether React root render requested and [startup][renderer] webview runtime ready appear after the restart. Please continue to redact credentials and provider URLs from any logs.

Additional reproduction on Windows:

• VS Code: 1.133.0
• Broken: openai.chatgpt 26.803.61601
• Working after rollback: openai.chatgpt 26.727.40816

With 26.803.61601, the log showed:

[CodexMcpConnection] Initialize received
[statsig-refresh-diagnostics] React root render requested
[chatgpt-account-lookup] ... result=succeeded
[CodexWebviewProvider] Webview did not finish starting extensionVersion=26.803.61601 role=sidebar

I then rolled back only the Codex extension to 26.727.40816, restarted VS Code, and the Codex panel loaded normally on the same machine and workspace.

This looks consistent with a Webview initialization/readiness regression in the 26.803.x extension rather than an authentication or workspace-specific issue.

Thanks for the detailed evidence. It confirms that your failure occurs before app-main executes, so I added an explicit asset-graph fallback in aebe033.感谢提供这些详细的证据。它们证实你的错误发生在 app-main 执行之前，因此我在 aebe033 中添加了明确的资源图回退方案。 。。。

目前还是不行

Result of -ResetAssetGraph test for codex-webview-fix

Tested commit:

aebe0339e621b975814e49165d30d4db34e5540f

Environment

OS: Windows x64
VS Code: 1.132.1
Codex extension: openai.chatgpt 26.803.61601
Authentication: API key mode (credentials and provider URL redacted)
VS Code/system/proxy environment: no proxy configured during the failed startup

The same machine and configuration work with openai.chatgpt 26.727.40816.

Pre-application validation

I audited commit aebe033 and tested it against an isolated extraction of the official 26.803.61601 Windows x64 VSIX.

Verified results:

Original asset count: 4,456
Generated asset count: 4,456
Static modulepreload links after patch: 0
Stylesheet links retained: 3
Dynamic preload dependencies: CSS only
Generated entry: node --check passed
Repeated -ResetAssetGraph: idempotent
Restore: original index hash restored and generated asset directory removed
Two-level rollback: readiness -> asset fallback -> readiness -> official files passed

Real installation apply output

Patched openai.chatgpt 26.803.61601 with an isolated asset graph
Extension: C:\Users\xiaoy\.vscode\extensions\openai.chatgpt-26.803.61601
Assets: C:\Users\xiaoy\.vscode\extensions\openai.chatgpt-26.803.61601\webview\assets-cache-bust-67fad9723414
Backup: C:\Users\xiaoy\AppData\Local\CodexWebviewReadinessFix\backups\26.803.61601-20260813-184510-284-c4f94c49
Restart every VS Code window. Reload affected windows sequentially.

Post-apply checks on the real installation:

Active extension version: 26.803.61601
Pinned: true
Generated namespace exists: true
Original assets: 4,456
Isolated assets: 4,456
Static modulepreloads: 0
Stylesheets retained: 3
Old ./assets/ references in index.html: 0
New namespace references in index.html: 4
Runtime marker bundle count: 1
Generated entry node --check: passed
Extension main: ./out/extension.js

Runtime result

After fully restarting VS Code, the sidebar still displayed:

Codex could not start
The extension couldn't load its resources.

Redacted log excerpt:

2026-08-13 18:46:04.017 [info] Activating Codex extension
2026-08-13 18:46:04.017 [info] [CodexMcpConnection] Spawning codex app-server
2026-08-13 18:46:05.351 [info] [CodexMcpConnection] Initialize received id=1
2026-08-13 18:46:35.758 [error] [CodexWebviewProvider] Webview did not finish starting extensionVersion=26.803.61601 role=sidebar

Milestone search result:

React root render requested: NOT PRESENT
[startup][renderer] webview runtime ready: NOT PRESENT
app routes mounted: NOT PRESENT
ready provider mounted: NOT PRESENT
Webview did not finish starting: PRESENT

No API key, token, custom provider URL, or request query string is included here.

Interpretation

The fallback was applied correctly, but the Webview still did not execute far enough to emit any renderer milestone. This suggests that the failure is earlier than the patched runtime and persists even with:

• a complete copied asset graph;
• a fresh asset URL namespace;
• no static JavaScript modulepreload links; and
• CSS-only dynamic preload dependencies.

The normal VS Code logs did not contain a specific failed-resource, CSP, modulepreload, or Service Worker error. The next useful evidence likely requires Developer: Open Webview Developer Tools and its Console/Network output, because errors before the webview-to-host log channel initializes are not forwarded to Codex.log.

Follow-up: Codex desktop fully closed

I repeated the real-machine test after explicitly excluding interference from the Codex desktop application:

1. Closed every VS Code window and confirmed Code.exe count was zero.
2. Confirmed no Codex process from the VS Code extension was running.
3. Reinstalled official openai.chatgpt 26.803.61601.
4. Applied -ResetAssetGraph, producing namespace assets-cache-bust-b42322667ada with all 4,456 assets.
5. Fully exited the Codex desktop application.
6. Started only VS Code and opened the Codex sidebar.

The failure remained unchanged:

2026-08-13 18:53:53.519 [info] [CodexMcpConnection] Initialize received id=1
2026-08-13 18:54:28.004 [error] [CodexWebviewProvider] Webview did not finish starting extensionVersion=26.803.61601 role=sidebar

Milestones:

React root render requested: NOT PRESENT
[startup][renderer] webview runtime ready: NOT PRESENT
app routes mounted: NOT PRESENT
ready provider mounted: NOT PRESENT
Webview did not finish starting: PRESENT

Process timing independently confirms that Codex desktop was not running during the failure:

VS Code log session created: 2026-08-13 18:53:41
Webview watchdog fired: 2026-08-13 18:54:28
Codex desktop restarted afterward: 2026-08-13 18:54:45

Closing Codex desktop therefore does not change this reproduction and rules out desktop/IDE shared IPC as the cause of the pre-entry Webview failure.

Thanks for testing this so thoroughly. This result rules out the stale asset namespace and JavaScript modulepreload hypotheses for this machine. The fallback was applied correctly, but the failure still occurs before any renderer milestone reaches the extension host.

I do not want to add another blind workaround without evidence from the failing layer. The normal Codex.log cannot see errors that occur before the webview-to-host channel starts, so could you collect the following from the failing 26.803.61601 session with -ResetAssetGraph still applied?

1. Open the Codex sidebar and wait for the failure.
2. Run Developer: Open Webview Developer Tools.
3. In Console, enable Preserve log and share the first red error plus its stack.
4. In Network, enable Preserve log, reload the affected VS Code window once, and share the failed requests with their status, resource path, type, and initiator.

The most useful detail is whether the generated index-BEwQuALC.js is loaded and evaluated, and whether its runtime, app-initial, or app-main imports fail. Screenshots or redacted text are preferable to a HAR file because request URLs may contain sensitive data.

For now I am treating -ResetAssetGraph as disproven for this reproduction rather than layering another speculative patch on top of it.

Thanks for testing this so thoroughly. This result rules out the stale asset namespace and JavaScript modulepreload hypotheses for this machine. The fallback was applied correctly, but the failure still occurs before any renderer milestone reaches the extension host.

是这样的错误信息：

workbench.desktop.main.js:sourcemap:442 INFO [AgentHost:renderer] Acquiring MessagePort to agent host...
workbench.desktop.main.js:sourcemap:442 INFO [AgentHost:renderer] MessagePort acquired, creating client...
workbench.desktop.main.js:sourcemap:442 INFO Started local extension host with pid 4556.
workbench.desktop.main.js:sourcemap:442 ERR Extension 'Tencent-Cloud.coding-copilot CANNOT USE these API proposals 'inlineCompletionsAdditions, findFiles2, terminalSelection, findTextInFiles, terminalExecuteCommandEvent, textDocumentChangeReason, extensionsAny'. You MUST start in extension development mode or use the --enable-proposed-api command line flag
pG @ workbench.desktop.main.js:sourcemap:442
workbench.desktop.main.js:sourcemap:442 ERR [vscode.mermaid-markdown-features]: Extension 'vscode.mermaid-markdown-features' CANNOT use 'legacyToolReferenceFullNames' without the 'chatParticipantPrivate' API proposal enabled
pG @ workbench.desktop.main.js:sourcemap:442
workbench.desktop.main.js:sourcemap:5781 Unrecognized feature: 'local-network-access'.
_createElement @ workbench.desktop.main.js:sourcemap:5781
workbench.desktop.main.js:sourcemap:5781 An iframe which has both allow-scripts and allow-same-origin for its sandbox attribute can escape its sandboxing.
mountTo @ workbench.desktop.main.js:sourcemap:5781
workbench.desktop.main.js:sourcemap:442 INFO [AgentHost:renderer] Protocol connection established; clientId=3de6ddb3-820a-4497-b6d2-c47f54d13ab7
workbench.desktop.main.js:sourcemap:442 INFO [AccountPolicyGate] apply: state=inactive, reason=undefined, isRestricted=false
workbench.desktop.main.js:sourcemap:442 INFO Settings Sync: Account status changed from uninitialized to unavailable
index.html?id=1aa5925d-db96-40d3-8692-9b0840507bea&parentId=1&origin=6bc90693-3892-470d-b14a-e59fe721495a&swVersion=6&extensionId=openai.chatgpt&platform=electron&vscode-resource-base-authority=vscode-resource.vscode-cdn.net&parentOrigin=vscode-file%3A%2F%2Fvscode-app&purpose=webviewView:1038 Unrecognized feature: 'local-network-access'.
(anonymous) @ index.html?id=1aa5925d-db96-40d3-8692-9b0840507bea&parentId=1&origin=6bc90693-3892-470d-b14a-e59fe721495a&swVersion=6&extensionId=openai.chatgpt&platform=electron&vscode-resource-base-authority=vscode-resource.vscode-cdn.net&parentOrigin=vscode-file%3A%2F%2Fvscode-app&purpose=webviewView:1038
workbench.desktop.main.js:sourcemap:442 ERR [Extension Host] (node:4556) [DEP0040] DeprecationWarning: The punycode module is deprecated. Please use a userland alternative instead.
(Use Code --trace-deprecation ... to show where the warning was created)
pG @ workbench.desktop.main.js:sourcemap:442
workbench.desktop.main.js:sourcemap:1095 [Extension Host] (node:4556) [DEP0040] DeprecationWarning: The punycode module is deprecated. Please use a userland alternative instead.
(Use Code --trace-deprecation ... to show where the warning was created)
COi @ workbench.desktop.main.js:sourcemap:1095
workbench.desktop.main.js:sourcemap:442 INFO [AgentHost] No token resolved for resource: https://api.github.com
workbench.desktop.main.js:sourcemap:442 ERR [Extension Host] (node:4556) [DEP0169] DeprecationWarning: url.parse() behavior is not standardized and prone to errors that have security implications. Use the WHATWG URL API instead. CVEs are not issued for url.parse() vulnerabilities.
pG @ workbench.desktop.main.js:sourcemap:442
workbench.desktop.main.js:sourcemap:1095 [Extension Host] (node:4556) [DEP0169] DeprecationWarning: url.parse() behavior is not standardized and prone to errors that have security implications. Use the WHATWG URL API instead. CVEs are not issued for url.parse() vulnerabilities.
COi @ workbench.desktop.main.js:sourcemap:1095
workbench.desktop.main.js:sourcemap:1095 [Extension Host] [AcpMessageRouter] postConstruct called, agentManagerService available: true
workbench.desktop.main.js:sourcemap:1095 [Extension Host] [AcpMessageRouter] subscribeToMessages called, agentManagerService: true
workbench.desktop.main.js:sourcemap:1095 [Extension Host] [AcpMessageRouter] Subscribing to messageport messages (early)
workbench.desktop.main.js:sourcemap:1095 [Extension Host] [Inline Chat] decorations disabled
workbench.desktop.main.js:sourcemap:442 INFO [AgentHost] No token resolved for resource: https://api.github.com
workbench.desktop.main.js:sourcemap:442 INFO [AgentHost] No token resolved for resource: https://api.github.com/repos
workbench.desktop.main.js:sourcemap:442 INFO [AgentHost] No token resolved for resource: https://api.github.com/repos
workbench.desktop.main.js:sourcemap:442 INFO [AgentHost] No token resolved for resource: https://api.github.com
workbench.desktop.main.js:sourcemap:1095 [Extension Host] [MemoryManager] preload global config: enabled=true, localMemoryEnabled=false, updatedAt=2026-07-22T01:39:19.880Z
workbench.desktop.main.js:sourcemap:442 INFO [AgentHost] No token resolved for resource: https://api.github.com
workbench.desktop.main.js:sourcemap:442 INFO [AgentHost] No token resolved for resource: https://api.github.com/repos
index.html?id=1aa5925d-db96-40d3-8692-9b0840507bea&parentId=1&origin=6bc90693-3892-470d-b14a-e59fe7…:1 Loading the font 'data:font/woff2;base64,d09GMgABAAAAAA4oAA4AAAAAHbQAAA3TAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAABmAAgRQIDgmcDBEICo1oijYBNgIkA14LMgAEIAWJAAeBHAyBHBvbGiMRdnO0IkRRkiYDgr9KsJ1NUAf2kILNxgUmgqIgq1P89vcbIcmsQbRps3vCcXdYOKSWEPEKgZgQkprQQsxIXUgq0DqpGKmIvrgkeVGtEQD9DzAO29fM9jYhxZEsL2FeURH2JN4MIcTdO049NCVdxQ/w9NrSYFEBKTDKpLKfNkCGDc1RwjZLQcm3vqJ2UW9Xfa3tgAHz6ivp6vgC2yD4/6352ndnN0X0TL7seypkjZlMsjmZnf0Mm5Q+JykRWQBKCVCVPbARPXWyQtb5VgLB6Biq7/Uixcj2WGqdI8tGSgkuRG+t910GKP2D7AQH0DB9FMDW/obJZ8giFI3Wg8Cvevz0M+5m0rTh7XDBlvo9Y4vm13EXmftt...mCahLsdlyA5fdQkRSan9LgnnLEyGSkaKJCJog0wAgvepWBt80+1yKln1bMVtCljfNWDueKLsWwaEbBSfSPTEmVRsUcYYMnEjcjeyCZzBXK9E9BYBXLKjOSpUDR+nEV3TFSUdQaz+ot98QxgXwx0GQ+EEUAKB2qZPkQQ0GqFD8UPFMqyaCHM24BZmSGic9EYMagKizOw9Hz50DMrDLrqqLkTAhplMictiCAx5S3BIUQdeJeLnBy2CNtMfz6cV4u8XKoFZQesbf9YZiIERiHjaNodDW6LgcirX/mPnJIkBGDUpTBhSa0EIr38D5hCIszhCM8URGBqImoWjpvpt1ebu/v3Gl3qJfMnNM+9V+kiRFyROTPHQWOcs1dNW94/ukKMPZBvDi55i5CttdeJz84DLngLqjcdwEZ87bFFR8CIG35OAkDVN6VRDZ7aq67NteYqZ2lpT8oYB2CytoBd6VuAx4WgiAsnuj3WohG+LugzXiQRDeM3XYXlULv4dp5VFYC' violates the following Content Security Policy directive: "font-src 'self' https://.vscode-cdn.net". The action has been blocked.
workbench.desktop.main.js:sourcemap:442 INFO [AgentHost] No token resolved for resource: https://api.github.com/repos
app-initial-CM3BD-Et.js:10 Uncaught SyntaxError: Unexpected identifier 'cloud'
workbench.desktop.main.js:sourcemap:1095 [Extension Host] [EnhancedMonitor] crashLogsDir not configured, crash monitoring disabled
workbench.desktop.main.js:sourcemap:1095 [Extension Host] [AcpMessageRouter] initialize called, already initialized: false , subscribed: true
workbench.desktop.main.js:sourcemap:1095 [Extension Host] [AcpMessageRouter] already subscribed, skipping
workbench.desktop.main.js:sourcemap:1095 [Extension Host] [AcpMessageRouter] Bridge initialized
workbench.desktop.main.js:sourcemap:1095 [Extension Host] [AgentManagerService] vscode.agentManager is not available
COi @ workbench.desktop.main.js:sourcemap:1095
workbench.desktop.main.js:sourcemap:1095 [Extension Host] [BillingService] User not logged in, skipping usage notification check
workbench.desktop.main.js:sourcemap:1095 [Extension Host] [Inline Chat] decorations disabled
workbench.desktop.main.js:sourcemap:1095 [Extension Host] [Inline Chat] decorations disabled
workbench.desktop.main.js:sourcemap:1095 [Extension Host] WebviewInfoService activate() called - DEBUG
workbench.desktop.main.js:sourcemap:1095 [Extension Host] WebviewInfoService commands registered extensionContext: true
workbench.desktop.main.js:sourcemap:1095 [Extension Host] 🔍[AgentManagerService] activate called, already initialized: false
workbench.desktop.main.js:sourcemap:1095 [Extension Host] [AgentManagerService] vscode.agentManager is NOT available
COi @ workbench.desktop.main.js:sourcemap:1095
workbench.desktop.main.js:sourcemap:1095 [Extension Host] [AgentManagerService] MessagePort channel initialized
workbench.desktop.main.js:sourcemap:1095 [Extension Host] StartNewChatCommand init undefined
workbench.desktop.main.js:sourcemap:1095 [Extension Host] InlineChatIDEDecorationProvider activated
workbench.desktop.main.js:sourcemap:1095 [Extension Host] [Inline Chat IDE] Initializing decorations
workbench.desktop.main.js:sourcemap:1095 [Extension Host] [Inline Chat] decorations enabled
workbench.desktop.main.js:sourcemap:442 INFO [perf] Render performance baseline is 10ms
workbench.desktop.main.js:sourcemap:1095 [Extension Host] [Inline Chat] decorations disabled
workbench.desktop.main.js:sourcemap:1095 [Extension Host] rejected promise not handled within 1 second: Error: Git model not found
COi @ workbench.desktop.main.js:sourcemap:1095
workbench.desktop.main.js:sourcemap:1095 [Extension Host] stack trace: Error: Git model not found
at xs.getAPI (d:\Programs\Microsoft VS Code\a5b5009513\resources\app\extensions\git\dist\main.js:115:33022)
at c:\Users\xiaoy\.vscode\extensions\tencent-cloud.coding-copilot-4.10.35413651\out\extension\index.js:1:1479636
COi @ workbench.desktop.main.js:sourcemap:1095
workbench.desktop.main.js:sourcemap:1126 [vscode.git]Git model not found
$onExtensionRuntimeError @ workbench.desktop.main.js:sourcemap:1126
workbench.desktop.main.js:sourcemap:1126 Error: Git model not found
at xs.getAPI (d:\Programs\Microsoft VS Code\a5b5009513\resources\app\extensions\git\dist\main.js:115:33022)
at c:\Users\xiaoy\.vscode\extensions\tencent-cloud.coding-copilot-4.10.35413651\out\extension\index.js:1:1479636
$onExtensionRuntimeError @ workbench.desktop.main.js:sourcemap:1126
workbench.desktop.main.js:sourcemap:442 ERR An unknown error occurred. Please consult the log for more details.
pG @ workbench.desktop.main.js:sourcemap:442
workbench.desktop.main.js:sourcemap:1095 [Extension Host] [EnhancedMonitor] crashLogsDir not configured, crash monitoring disabled
workbench.desktop.main.js:sourcemap:442 INFO Auto updating outdated extensions. anthropic.claude-code
workbench.desktop.main.js:sourcemap:442 ERR [Extension Host] (node:4556) [DEP0152] DeprecationWarning: Custom PerformanceEntry accessors are deprecated. Please use the detail property.
pG @ workbench.desktop.main.js:sourcemap:442
workbench.desktop.main.js:sourcemap:1095 [Extension Host] (node:4556) [DEP0152] DeprecationWarning: Custom PerformanceEntry accessors are deprecated. Please use the detail property.
COi @ workbench.desktop.main.js:sourcemap:1095
workbench.desktop.main.js:sourcemap:442 INFO [AccountPolicyGate] apply: state=inactive, reason=undefined, isRestricted=false
workbench.desktop.main.js:sourcemap:1095 [Extension Host] [DataFilter] Total: 1 → 0 (dropped: 1)
workbench.desktop.main.js:sourcemap:1095 [Extension Host] Created lock file at C:\Users\xiaoy\.claude\ide\10840.lock
workbench.desktop.main.js:sourcemap:1095 [Extension Host] Set CLAUDE_CODE_SSE_PORT=10840 in terminal environment (in-memory)
workbench.desktop.main.js:sourcemap:1095 [Extension Host] [DataFilter] Total: 3 → 0 (dropped: 3)
workbench.desktop.main.js:sourcemap:5781 Using standard dev tools to debug iframe based webview
workbench.desktop.main.js:sourcemap:5413 Codex couldn't load its resources.
onDidChangeNotification @ workbench.desktop.main.js:sourcemap:5413
(anonymous) @ workbench.desktop.main.js:sourcemap:5413
_deliver @ workbench.desktop.main.js:sourcemap:433
_deliverQueue @ workbench.desktop.main.js:sourcemap:433
fire @ workbench.desktop.main.js:sourcemap:433
addNotification @ workbench.desktop.main.js:sourcemap:1234
notify @ workbench.desktop.main.js:sourcemap:2107
(anonymous) @ workbench.desktop.main.js:sourcemap:1139
_showMessage @ workbench.desktop.main.js:sourcemap:1139
$showMessage @ workbench.desktop.main.js:sourcemap:1139
_doInvokeHandler @ workbench.desktop.main.js:sourcemap:5457
_invokeHandler @ workbench.desktop.main.js:sourcemap:5457
_receiveRequest @ workbench.desktop.main.js:sourcemap:5457
_receiveOneMessage @ workbench.desktop.main.js:sourcemap:5457
(anonymous) @ workbench.desktop.main.js:sourcemap:5457
_deliver @ workbench.desktop.main.js:sourcemap:433
fire @ workbench.desktop.main.js:sourcemap:433
fire @ workbench.desktop.main.js:sourcemap:1141
(anonymous) @ workbench.desktop.main.js:sourcemap:5472
workbench.desktop.main.js:sourcemap:1095 [Extension Host] [DataFilter] Total: 69 → 9 (dropped: 60)

This contains the first actionable renderer error:

app-initial-CM3BD-Et.js:10 Uncaught SyntaxError: Unexpected identifier 'cloud'

The font CSP warning and the errors from unrelated extensions are not the startup blocker here.

I reproduced the exact aebe033 fallback against the official 26.803.61601 bundle and checked every JavaScript file modified by the fallback. The generated entry, app-main, and app-initial all pass node --check. For comparison, the deterministic app-initial-CM3BD-Et.js values are:

official SHA-256: AB49759352A868ADC8BD10B46A6F13E1FB9DDF23E642A9BFABD433394C443070
patched SHA-256:  3405F01B8387EA1A27370340C2FFA5E427A81A3A93D68F9B42003B9033D05E15
patched size:     3058542 bytes

The patch to that file only removes the delayed dispatchMessage(ready,{}) expression, and the resulting surrounding syntax is valid locally. We now need to distinguish an on-disk difference from a corrupted/stale Webview response.

Could you provide these two items?

1. The SHA-256 and size of the generated assets-cache-bust-*\app-initial-CM3BD-Et.js on the failing installation.
2. In Webview Developer Tools, click the app-initial-CM3BD-Et.js:10 error and share the exact line/column plus a short redacted excerpt around the highlighted cloud token. In Network, the request URL, status, transferred/resource size, and Response excerpt for that same file would also be useful.

If the disk hash differs from the value above, the installed generated file was altered. If it matches but the DevTools response does not, the failure is in the VS Code Webview resource/cache path rather than the JavaScript transformation itself.

This contains the first actionable renderer error: ```

非常感谢，我自己修好了

这是我修复的脚本
Apply-CodexWebviewReadinessFix.zip

原因如下：

Result of -ResetAssetGraph test for codex-webview-fix

Tested commit:

aebe0339e621b975814e49165d30d4db34e5540f

Environment

OS: Windows x64
VS Code: 1.132.1
Codex extension: openai.chatgpt 26.803.61601
Authentication: API key mode (credentials and provider URL redacted)
VS Code/system/proxy environment: no proxy configured during the failed startup

The same machine and configuration work with openai.chatgpt 26.727.40816.

Pre-application validation

I audited commit aebe033 and tested it against an isolated extraction of the official 26.803.61601 Windows x64 VSIX.

Verified results:

Original asset count: 4,456
Generated asset count: 4,456
Static modulepreload links after patch: 0
Stylesheet links retained: 3
Dynamic preload dependencies: CSS only
Generated entry: node --check passed
Repeated -ResetAssetGraph: idempotent
Restore: original index hash restored and generated asset directory removed
Two-level rollback: readiness -> asset fallback -> readiness -> official files passed

Real installation apply output

Patched openai.chatgpt 26.803.61601 with an isolated asset graph
Extension: C:\Users\xiaoy\.vscode\extensions\openai.chatgpt-26.803.61601
Assets: C:\Users\xiaoy\.vscode\extensions\openai.chatgpt-26.803.61601\webview\assets-cache-bust-67fad9723414
Backup: C:\Users\xiaoy\AppData\Local\CodexWebviewReadinessFix\backups\26.803.61601-20260813-184510-284-c4f94c49
Restart every VS Code window. Reload affected windows sequentially.

Post-apply checks on the real installation:

Active extension version: 26.803.61601
Pinned: true
Generated namespace exists: true
Original assets: 4,456
Isolated assets: 4,456
Static modulepreloads: 0
Stylesheets retained: 3
Old ./assets/ references in index.html: 0
New namespace references in index.html: 4
Runtime marker bundle count: 1
Generated entry node --check: passed
Extension main: ./out/extension.js

Runtime result

After fully restarting VS Code, the sidebar still displayed:

Codex could not start
The extension couldn't load its resources.

Redacted log excerpt:

2026-08-13 18:46:04.017 [info] Activating Codex extension
2026-08-13 18:46:04.017 [info] [CodexMcpConnection] Spawning codex app-server
2026-08-13 18:46:05.351 [info] [CodexMcpConnection] Initialize received id=1
2026-08-13 18:46:35.758 [error] [CodexWebviewProvider] Webview did not finish starting extensionVersion=26.803.61601 role=sidebar

Milestone search result:

React root render requested: NOT PRESENT
[startup][renderer] webview runtime ready: NOT PRESENT
app routes mounted: NOT PRESENT
ready provider mounted: NOT PRESENT
Webview did not finish starting: PRESENT

No API key, token, custom provider URL, or request query string is included here.

Interpretation

The fallback was applied correctly, but the Webview still did not execute far enough to emit any renderer milestone. This suggests that the failure is earlier than the patched runtime and persists even with:

• a complete copied asset graph;
• a fresh asset URL namespace;
• no static JavaScript modulepreload links; and
• CSS-only dynamic preload dependencies.

The normal VS Code logs did not contain a specific failed-resource, CSP, modulepreload, or Service Worker error. The next useful evidence likely requires Developer: Open Webview Developer Tools and its Console/Network output, because errors before the webview-to-host log channel initializes are not forwarded to Codex.log.

Follow-up: Codex desktop fully closed

I repeated the real-machine test after explicitly excluding interference from the Codex desktop application:

1. Closed every VS Code window and confirmed Code.exe count was zero.
2. Confirmed no Codex process from the VS Code extension was running.
3. Reinstalled official openai.chatgpt 26.803.61601.
4. Applied -ResetAssetGraph, producing namespace assets-cache-bust-b42322667ada with all 4,456 assets.
5. Fully exited the Codex desktop application.
6. Started only VS Code and opened the Codex sidebar.

The failure remained unchanged:

2026-08-13 18:53:53.519 [info] [CodexMcpConnection] Initialize received id=1
2026-08-13 18:54:28.004 [error] [CodexWebviewProvider] Webview did not finish starting extensionVersion=26.803.61601 role=sidebar

Milestones:

React root render requested: NOT PRESENT
[startup][renderer] webview runtime ready: NOT PRESENT
app routes mounted: NOT PRESENT
ready provider mounted: NOT PRESENT
Webview did not finish starting: PRESENT

Process timing independently confirms that Codex desktop was not running during the failure:

VS Code log session created: 2026-08-13 18:53:41
Webview watchdog fired: 2026-08-13 18:54:28
Codex desktop restarted afterward: 2026-08-13 18:54:45

Closing Codex desktop therefore does not change this reproduction and rules out desktop/IDE shared IPC as the cause of the pre-entry Webview failure.

Webview DevTools root cause

The first fatal Console error from the failing Webview was:

app-initial-CM3BD-Et.js:10 Uncaught SyntaxError: Unexpected identifier 'cloud'

The earlier local-network-access and font CSP messages were warnings and were not the startup-stopping error.

The token cloud is valid in the official bundle. The syntax error was caused earlier on the same line by text corruption in the generated asset tree. The official text was:

`${t.slice(0,ev-1)}…`

The generated file contained:

`${t.slice(0,ev-1)}鈥}

The ellipsis was decoded through the Windows ANSI code page and the closing backtick was lost, leaving the template literal unterminated. Chromium then reported the next relevant identifier, cloud, as unexpected.

Environment:

Windows PowerShell: 5.1.26100.9168
[System.Text.Encoding]::Default.WebName: gb2312
VS Code: 1.133.0 x64

The script reads JavaScript and HTML using Get-Content -Raw without an explicit encoding, then writes them as UTF-8. On Windows PowerShell 5.1 this decodes UTF-8 source through the system ANSI code page, corrupting non-ASCII content before it is written.

A local candidate fix replaces text reads with strict UTF-8 File.ReadAllText:

$utf8WithoutBom = New-Object System.Text.UTF8Encoding($false)
$utf8Strict = New-Object System.Text.UTF8Encoding($false, $true)

function Read-Utf8Text {
    param([string]$Path)
    return [System.IO.File]::ReadAllText($Path, $utf8Strict)
}

All source-bearing Get-Content -Raw calls are then routed through Read-Utf8Text.

Isolated validation against the official 26.803.61601 bundle:

app-initial original bytes: 3,058,573
app-initial generated bytes: 3,058,542
byte delta: -31
ellipsis count, original/generated: 74 / 74
Unicode replacement characters: 0
remaining delayed ready dispatches: 0
runtime-ready marker present: true
app-initial node --check: passed
app-main node --check: passed
generated entry node --check: passed

This explains why the fallback appeared correctly installed yet failed before every renderer milestone: the fallback namespace itself contained a syntactically corrupted route bundle.

Thanks, this identifies a real bug in the script. Windows PowerShell 5.1 decoded the UTF-8 bundle through the system ANSI code page, corrupting non-ASCII text before rewriting it.

I merged your fix as codex-webview-fix#1. I also verified both the normal patch and -ResetAssetGraph using Windows PowerShell 5.1 against the official 26.803.61601 bundle:

• all 74 ellipsis characters are preserved;
• no Unicode replacement characters are introduced;
• the generated entry, app-main, and app-initial pass syntax checks;
• repeated application remains idempotent;
• restore returns the original file hashes and removes the generated asset tree.

Your diagnosis and fix were correct. Thanks for tracing the actual response down to the corrupted template literal and contributing the patch.

Hi everyone, we just released an update (26.810.41047 stable / 26.5810.41047 pre-release) that fixes the startup watchdog issue. After updating, you should no longer see “The extension couldn’t load its resources” simply because application initialization takes longer than 30 seconds.

Keep in mind that while the resource-loading error won't appear anymore, if an underlying networking or authentication problem was preventing initialization from completing, that will likely still be the case. If the extension remains stuck after you update, please check your proxy and VPN settings, and then file a bug report. Indefinitely pending account requests will continue to be tracked separately in #37521.

Thanks again to everyone who reported this issue and shared diagnostic information.

Note: Windows packages are available through the VS Code Marketplace. Windows packages are not currently available through Open VSX while we work to resolve a package-size publishing issue.

Hi @alexr-oai, could you please help take a look at this issue and advise on an official fix?

We are seeing the same user-facing failure again in two Linux Dev Containers (triplet-Comm and PCBGL2):

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

Current environment:

• VS Code 1.134.0 (110a328ea54b42367b803ec53ee0bf52ef26b419)
• Codex extension openai.chatgpt-26.820.60940-linux-x64
• Dev Containers 0.466.0 over Remote SSH 0.126.0

The current failure happens before the extension fully activates. The renderer/remote extension-host logs repeatedly show:

PendingMigrationError: navigator is now a global in nodejs
at .../openai.chatgpt-26.820.60940-linux-x64/out/extension.js:1:11415

We verified that only one Codex extension version is registered in each container, the extension files are intact, and SSH/container connectivity is healthy. Enabling extensions.supportNodeGlobalNavigator: true both locally and in each container's remote machine settings appears to be the relevant workaround.

We also checked the workaround in the earlier comment above. That workaround targets the older webview startup.whenReady() / missing ready handshake. In the current 26.820.60940 bundle, the renderer already has a renderer_ready path, while the extension now fails earlier during Node extension-host loading, so applying the old bundle replacement does not appear appropriate.

Could you please confirm whether this is a Codex extension compatibility regression with the current VS Code Node extension host, and whether the extension can update its Node/web environment detection so users do not need to enable this compatibility setting manually?