VS Code Webview fails to load because the ChatGPT extension preloads up to 676 JS/CSS assets concurrently

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #34103
• #34187
• #33985

Powered by Codex Action

This issue was identified and resolved by gpt5.6-sol. The solution works well across multiple versions. Below is the report and proposed fix provided by gpt5.6-sol.

Summary

In version openai.chatgpt-26.715.31925, the VS Code extension Webview entry point may attempt to preload up to 676 JavaScript and CSS resources in a single batch.

Because VS Code Webviews rely on a Service Worker to serve local extension resources, the large number of concurrent modulepreload requests can overwhelm or invalidate the Webview loading process.

This can cause the Codex/ChatGPT Webview to remain stuck on the loading animation or display a blank, gray, or otherwise unresponsive screen.

Affected version

• Extension version: openai.chatgpt-26.715.31925
• Environment: VS Code Webview
• Component: Codex/ChatGPT extension frontend

Observed behavior

The Webview may fail to initialize and show one or more of the following symptoms:

• The loading animation never completes
• Blank or gray Webview
• JavaScript or CSS preload failures
• Service Worker registration failure
• Local Webview resources fail with net::ERR_FAILED

The developer console may also contain errors or warnings similar to:

potential listener LEAK
net::ERR_FAILED
CSS/JS preload failed
Service Worker registration failed because the document state became invalid

Root cause

The generated Webview entry point invokes the preload helper with a very large dependency list.

The helper in:

preload-helper-D1M5K2pS.js

creates preload elements for both CSS files and JavaScript modules. In the affected build, this results in hundreds of concurrent JavaScript modulepreload requests in addition to the CSS requests.

VS Code Webview resources are served through a Service Worker. Issuing several hundred local resource requests concurrently appears to cause request failures, excessive event listeners, or invalidation of the document state during Service Worker registration.

As a result, one or more required frontend modules fail to load and the application never finishes bootstrapping.

Working fix

1. Restrict the preload helper to CSS files

Modify preload-helper-D1M5K2pS.js so that the preload dependency list only contains CSS resources:

i = i.filter(e => e.endsWith(".css"))

This prevents the helper from creating hundreds of JavaScript modulepreload elements.

2. Bundle the JavaScript module graph

Use esbuild to bundle the complete JavaScript module graph into a single entry file:

index-codex-bundled-v2.js

Generated bundle size:

131,325,214 bytes

3. Update the Webview entry point

Modify the Webview index.html so that its main script points directly to the bundled file instead of the original multi-module entry point.

Conceptually:

<script type="module" src="./index-codex-bundled-v2.js"></script>

After these changes, the Webview loads successfully because:

• Only CSS resources are preloaded
• The JavaScript application is fetched as a single bundle
• The Service Worker no longer needs to handle hundreds of simultaneous JavaScript module requests
• The Webview initialization completes without becoming stuck on the loading screen

Expected behavior

The extension Webview should load reliably without generating hundreds of concurrent modulepreload requests.

The production build should either:

1. Bundle the frontend into a smaller number of JavaScript chunks suitable for a VS Code Webview, or
2. Avoid generating modulepreload tags for the entire JavaScript dependency graph, or
3. Limit or batch preload requests so that the Webview Service Worker is not overwhelmed.

Suggested upstream fix

Please adjust the extension build or runtime preload logic so that JavaScript dependencies are not all preloaded concurrently.

A minimal mitigation would be to preload CSS only:

dependencies = dependencies.filter(file => file.endsWith(".css"))

A more robust solution would be to configure the production build to emit a limited number of JavaScript chunks, or a single Webview-compatible bundle, rather than relying on hundreds of module requests.

Additional notes

This appears to be specific to the interaction between Vite-generated module preload behavior and the VS Code Webview resource-loading architecture. The same asset graph may work in a normal browser environment but fail inside a Webview because local extension resources are mediated by the Webview Service Worker.

I encountered the same Codex Webview error on Fedora:

Error loading webview: Error: Could not register service worker:
InvalidStateError: Failed to register a ServiceWorker:
The document is in an invalid state.

Reloading VS Code, reloading the Webview, and installing an earlier 26.715.x extension version did not help.

I then uninstalled the Codex extension, completely closed VS Code, and cleared the VS Code Webview/cache directories:

pkill -TERM -f '/usr/share/code/code' 2>/dev/null || true
sleep 3

rm -rf \
  ~/.config/Code/"Service Worker" \
  ~/.config/Code/Cache \
  ~/.config/Code/"Code Cache" \
  ~/.config/Code/GPUCache \
  ~/.config/Code/CachedData \
  /tmp/codex-ipc

code

After reopening VS Code, I reinstalled the latest Codex extension. The Codex Webview then loaded normally again.

Environment:

OS: Fedora release 44 (Forty Four)
VS Code: 1.129.1
VS Code commit: 8a7abeba6e03ea3af87bfbce9a1b7e48fed567b8
Architecture: x64
Codex extension after reinstall: openai.chatgpt@26.715.61943

This appears to be a workaround involving a clean extension reinstall together with clearing the VS Code Webview/service-worker cache, rather than a fix for the underlying issue.

I had this problem. I asked Codex CLI to apply the fixes from this issue and it's now working fine.