VS Code extension: Codex panel hangs at logo forever in every window after the first — webview module-preload storm trips Chromium service-worker fetch limit ("insufficient resources")

Environment

• Codex IDE extension: 26.715.31925 (linux-x64); behavior reproduced across multiple earlier versions (26.707.x line as well) — long-standing, not a fresh regression
• VS Code: 1.129.1 (commit 8a7abeba6e03ea3af87bfbce9a1b7e48fed567b8), rpm install
• OS: Fedora 43, kernel 7.1.3, KDE Plasma on Wayland, Nvidia 580.173.02
• Note: "disable-hardware-acceleration": true in argv.json (does not affect the outcome; issue reproduced with and without)

Summary

With one VS Code window open, Codex works. In any second window of the same VS Code process (File → New Window, with or without a folder), the Codex panel shows the logo splash forever. No error is surfaced anywhere — extension log simply stops after Initialize received; the webview milestones (React root render requested / Features enabled / routes mounted) never occur. Backend (codex app-server) is healthy: it spawns, answers initialize, and IPC broadcasts from the first window's router are delivered to the second window.

Root cause (diagnosed via webview DevTools)

The webview bundle is code-split into hundreds of small chunks, and the Vite preload-helper injects <link rel="modulepreload"> for the entire dependency graph before importing app-main. In a secondary window, the host's resource reads back up (VS Code-side loadResource → doReadFileStream; listener count observed climbing 175 → 263 → 441 → 614+), until Chromium's cap on concurrent service-worker FetchEvents trips:

The FetchEvent for "<URL>" resulted in a network error response: insufficient resources.   (×50+)

After the cap trips, every subsequent resource request fails:

file+.vscode-resource.vscode-cdn.net/.../webview/assets/<chunk>.js  Failed to load resource: net::ERR_FAILED   (hundreds)
Uncaught Error: Unable to preload CSS for .../composer-approval-request-card-*.css  (preload-helper)
Uncaught TypeError: Failed to fetch dynamically imported module: .../app-main-BPH9pd0X.js

→ the app never boots; the static splash (logo) is all the user ever sees.

First windows usually win this race (reads complete before the cap); secondary windows of the same process reliably lose it. Markdown preview and other small webviews work fine in the same broken window — only resource-heavy webviews are affected.

Reproduction

1. Open VS Code with the Codex extension; let Codex load in window 1.
2. File → New Window (same process; folder or no folder — irrelevant).
3. Open the Codex panel in window 2 → eternal logo.
4. Developer: Open Webview Developer Tools on the panel → console shows the errors above.

Verified fix (local patch, works immediately)

Editing webview/assets/preload-helper-*.js to skip non-CSS preload link injection (keeping the required CSS handling) fixes secondary windows completely — modules then load on demand in bounded waves. One-line change: after the helper's .css detection, early-return for JS deps. Verified: pre-patch, 6/6 secondary windows hung with the errors above; post-patch, secondary windows mount routes in ~1.5 s with zero failed requests.

Suggested fixes upstream

• Limit preload concurrency (batch the modulepreload injection, e.g. ≤64 in flight), or drop JS modulepreload hints entirely in the webview build, or reduce chunk count (fewer/larger chunks) for the VS Code webview target.
• Independently: surface fatal webview boot failures to the user instead of an indefinite splash — a "failed to load, retry" state would have made this diagnosable years earlier. A related silent-hang complaint applies to other startup failures too (e.g. auth in a bad state produces the same eternal logo with no re-auth prompt).

Also relevant to VS Code

A companion report is filed as microsoft/vscode#326500 (https://github.com/microsoft/vscode/issues/326500) covering the host-side behavior (resource reads stalling under concurrent webview fetch load in multi-window sessions, with potential listener LEAK warnings in doReadFileStream/loadResource). Either side can fix this class: fewer concurrent requests from the extension, or non-collapsing resource serving in VS Code.