Extension webview can freeze workbench under large Vite modulepreload burst

## 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:

```text
potential listener LEAK detected
doReadFileStream
readFileStream
loadResource
```

The code-server server log also repeatedly showed:

```text
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:

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

The relevant pattern was:

```js
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:

```js
__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.

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.

Escrito por el modelo de indexación a partir del texto del issue.