Extension webview can freeze workbench under large Vite modulepreload burst

[SMOKE-19]

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:

• Codex IDE extension freezes code-server sidebar on desktop Chromium browsers openai/codex#28726
• final Codex-side follow-up: Codex IDE extension freezes code-server sidebar on desktop Chromium browsers openai/codex#28726 (comment)

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.

[linear-code]

DEVEX-504

[SMOKE-19]

Closing this myself as an informational report after documenting the local workaround and likely failure path.

[SMOKE-19]

Reopening this for tracking, because the issue is not fixed upstream yet and the current working mitigation is still only a local self-patch.

The related Codex-side issue is here:

openai/codex#28726

After more investigation, my current view is that this is a boundary issue between a heavy extension webview preload burst and code-server's webview/resource loading path.

The workaround that stopped the freeze locally was applied to the installed Codex extension bundle:

• reduce the generated Vite __vite__mapDeps([...]) preload list to CSS-only entries
• remove static modulepreload links from the webview index.html

That avoids the large initial JS/CSS resource burst when the Codex sidebar webview mounts. With that change, the desktop Chromium/Edge code-server client no longer freezes in my environment.

However, I do not think that local patch should be treated as a real resolution. Even if the triggering preload behavior is fixed or mitigated by the extension, this still exposed a code-server-side resilience issue:

large extension webview preload burst
→ code-server webview/resource loading bridge
→ desktop Chromium client behavior
→ listener/resource-load amplification
→ workbench freeze

The decisive browser console path included repeated logs such as:

potential listener LEAK detected
doReadFileStream
readFileStream
loadResource
RequestStore#acceptReply was called without receiving a matching request

So I am reopening this issue to keep the code-server side visible until maintainers can decide whether code-server should handle this class of large webview preload/resource bursts more gracefully, or whether it should be fully tracked as an extension-side behavior.

[code-asher]

I think this is a decision out of scope for code-server, we are just wrapping VS Code so if there is a fundamental issue with how webviews load I think we should open an issue upstream with VS Code (after confirming we can reproduce with Codespaces or VS Code web directly).