Repository navigation
Extension webview can freeze workbench under large Vite modulepreload burst #7867
Description
Activity
Closing this myself as an informational report after documenting the local workaround and likely failure path.
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:
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
modulepreloadlinks from the webviewindex.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 freezeThe decisive browser console path included repeated logs such as:
potential listener LEAK detected doReadFileStream readFileStream loadResource RequestStore#acceptReply was called without receiving a matching requestSo 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.
- reduce the generated Vite
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).
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:
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
openai.chatgpt@26.609.30741, linux-x64Symptom
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:
The code-server server log also repeatedly showed:
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:
The relevant pattern was:
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/loadResourcelistener leak andRequestStore#acceptReplymismatch, 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:
I also removed four static
modulepreloadlinks from the extension'swebview/index.html.Results:
Why this may matter for code-server
This was triggered by the Codex extension, but the hard-freeze failure mode seems broader:
Possible code-server-side mitigations might include:
readFileStream/loadResource,RequestStore#acceptReplymismatches fail gracefully,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.