Extension webview can freeze workbench under large Vite modulepreload burst

Start by tracing the webview resource path through readFileStream and loadResource, then inspect RequestStore#acceptReply while reproducing the large preload burst from the reported Codex webview entry and webview/index.html. Done means a large extension webview no longer freezes the desktop workbench or produces listener-leak and unmatched-request signals, but the issue does not provide a standalone reproducer.

Summary

An extension webview that eagerly preloads hundreds of local Vite chunks can freeze the code-server workbench on desktop Chromium-based browsers.

I originally investigated this as an OpenAI Codex extension issue:

• https://github.com/openai/codex/issues/28726
• final Codex-side follow-up: https://github.com/openai/codex/issues/28726#issuecomment-4762217105

The local workaround was applied inside the Codex extension bundle, but the failure path appears to involve code-server's webview resource loading bridge as well. I am filing this here as a closed informational issue because the same class of problem may affect other large extension webviews.

Environment

• Server OS: Arch Linux
• code-server: 4.123.0 / VS Code base 1.123.0 at the time of local testing
• Extension involved: openai.chatgpt@26.609.30741, linux-x64
• Affected clients:
  • Windows Edge / Chromium-based browsers
  • Arch Linux Chromium / Chrome-family browsers
• Less affected client:
  • Android Samsung Internet against the same code-server instance

Symptom

Opening the Codex sidebar in code-server caused the browser/workbench UI to freeze shortly after the webview iframe was mounted, before opening any specific thread.

Removing the extension avoided the freeze.

Relevant browser console / server log signals

Browser DevTools showed the freeze path going through workbench webview/resource loading:

potential listener LEAK detected
doReadFileStream
readFileStream
loadResource

The code-server server log also repeatedly showed:

RequestStore#acceptReply was called without receiving a matching request

These messages appeared at the time the sidebar webview was opened.

Local diagnosis

The generated Codex webview entry file contained a large Vite dependency preload list:

~/.local/share/code-server/extensions/openai.chatgpt-26.609.30741-linux-x64/webview/assets/index-CaOlcDW2.js

The relevant pattern was:

await e(() => import("./app-main-FqROzk9D.js"), __vite__mapDeps([0, 1, 2, ... 486]), import.meta.url)

That meant the extension webview attempted to preload hundreds of local JS/CSS assets as soon as the sidebar webview was mounted.

In code-server, those local webview asset requests flow through the browser/workbench resource bridge and extension file loading path. On desktop Chromium clients, this appeared to trigger the readFileStream / loadResource listener leak and RequestStore#acceptReply mismatch, then the workbench froze.

Workaround that fixed the freeze locally

I patched the generated extension webview entry so that only CSS chunks were preloaded, while the hundreds of JS chunks were no longer eagerly preloaded:

__vite__mapDeps([48,94,136,137,166,189,202,210,232,264,315,320,329,384,387,421,469,484,485,486])

I also removed four static modulepreload links from the extension's webview/index.html.

Results:

• Desktop Chromium / Edge no longer froze when opening the webview.
• Android Samsung Internet still rendered the UI correctly.
• Removing the preload list entirely avoided the desktop freeze but broke the UI on Android because CSS chunks were not loaded early enough.
• Keeping only CSS preloads preserved rendering while avoiding the desktop freeze.

Why this may matter for code-server

This was triggered by the Codex extension, but the hard-freeze failure mode seems broader:

• A large extension webview can issue a burst of hundreds of local asset requests.
• code-server's webview resource bridge appears able to enter a listener leak / request mismatch / freeze state under that burst.
• Other large Vite/React extension webviews could potentially hit the same path.

Possible code-server-side mitigations might include:

• throttling or batching webview local-resource requests,
• improving listener cleanup around readFileStream / loadResource,
• making RequestStore#acceptReply mismatches fail gracefully,
• avoiding full workbench freezes when an extension webview preloads too many local resources at once.

Closing note

I am closing this issue myself because I have a local workaround and cannot provide a minimal standalone reproducer right now. I am leaving the report in case it helps future investigation of code-server's webview resource bridge under large modulepreload bursts.