Extension webview can freeze workbench under large Vite modulepreload burst

Bắt đầu bằng cách lần theo đường dẫn tài nguyên webview qua readFileStream và loadResource, sau đó kiểm tra RequestStore#acceptReply trong khi tái hiện burst preload lớn từ mục webview Codex đã được báo cáo và webview/index.html. Được xem là hoàn tất khi một webview extension lớn không còn làm workbench desktop bị treo hoặc tạo ra các tín hiệu về listener leak và request không khớp, nhưng issue không cung cấp một reproducer độc lập.

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.