›_ Codex Issues
Codex Issues / #28726

Codex IDE extension freezes code-server sidebar on desktop Chromium browsers

Open 💬 18 comments Opened Jun 17, 2026 by SMOKE-19
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Codex IDE extension freezes code-server when opening the Codex sidebar on desktop Chromium-based browsers. The same code-server instance works normally without the Codex extension, and Android Samsung Internet can use the Codex sidebar much more reliably.

Environment

  • Server OS: Arch Linux
  • Server surface: code-server
  • code-server version: 4.123.0, VS Code base 1.123.0
  • Codex IDE extension version tested in code-server: openai.chatgpt-26.602.71036-linux-x64
  • Affected clients:
  • Arch Linux Chromium / Chrome / Edge-family Chromium browser
  • Windows Edge / Chrome-family Chromium browser
  • Less affected / working client:
  • Android Samsung Internet connecting to the same code-server instance

Symptoms

  • With the Codex extension installed, opening the Codex sidebar freezes the code-server browser UI.
  • The freeze happens before opening a specific thread, during sidebar / Codex home / thread list visualization.
  • The UI appears usable for a few seconds, then freezes after the sidebar is opened.
  • Removing the Codex extension makes code-server work normally.
  • Using a mobile Android user agent in desktop Chromium did not avoid the freeze.

Timeline

  • The issue started suddenly within the last week.
  • Arch Linux and code-server were updated after the first freeze, but the freeze persisted.
  • This makes the code-server update less likely to be the original trigger.

Reproduction Steps

  1. Run code-server on Arch Linux.
  2. Connect from a desktop Chromium-based browser.
  3. Install / enable the Codex IDE extension.
  4. Open the Codex sidebar.
  5. Observe the browser / code-server UI freezing during sidebar initialization.

Diagnostics Performed

  • Removed Codex extension: freeze disappeared.
  • Tested desktop Chromium with mobile-sized window, disabled browser extensions, and Android Samsung Internet user agent: freeze still reproduced.
  • Tested Android Samsung Internet against the same code-server server: Codex sidebar worked much more reliably.
  • Isolated Codex home for code-server:
  • Used separate CODEX_HOME=/home/smoke_nb_sv/.codex-code-server.
  • Copied only auth/config/installation id.
  • Large session files and old session index were excluded.
  • Quarantined large session files:
  • Original ~/.codex/sessions had about 211 MB total, largest file about 133 MB.
  • Moving large and old session files out did not fix the freeze.
  • Disabled plugin-related features for code-server's Codex app-server:
  • Launched app-server through a wrapper with:
  • --disable plugins
  • --disable remote_plugin
  • --disable plugin_sharing
  • Freeze still reproduced.
  • Disabled Codex Chat Session Item Provider registration in the extension bundle as a diagnostic patch.
  • Freeze still reproduced.
  • Dropped noisy IPC broadcasts in the extension bundle as a diagnostic patch:
  • thread-stream-state-changed
  • thread-read-state-changed
  • thread-queued-followups-changed
  • query-cache-invalidate
  • This reduced the earlier broadcast warning flood, but the freeze remained.
  • Disabled/replaced the recent thread list calculation in the webview bundle with an empty list as a diagnostic patch.
  • Freeze still reproduced.

Logs / Observations

Earlier logs repeatedly showed:

[IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed
Ignoring ipc-broadcast expectedVersion=6 method=thread-stream-state-changed ... version=7

After broadcast-drop diagnostics, that warning flood was reduced, but the freeze persisted.

Later remoteexthost.log showed workspace storage lock conflicts and multiple extension hosts:

EEXIST: file already exists, open '/home/.../.local/share/code-server/User/workspaceStorage/.../vscode.lock'
Lock ... Could not acquire lock, checking if the file is stale.
Lock ... The lock does not look stale, giving up.

During repeated reload/freeze tests, multiple code-server extensionHost processes and multiple Codex app-server processes accumulated. Several stale workspaceStorage/*/vscode.lock files pointed to dead extensionHost PIDs and had to be removed manually.

Current Hypothesis

This looks like a new compatibility issue in the combination of:

  • code-server
  • desktop Chromium-based browsers
  • Codex IDE extension webview/sidebar initialization
  • Codex app-server / IPC / VS Code ChatSession initialization
  • possibly workspaceStorage lock / repeated extensionHost startup behavior

It does not appear to be only a large local session-history issue, because isolating CODEX_HOME and removing large sessions did not fix it.

It does not appear to be only plugin/remote-plugin sync, because disabling those app-server features did not fix it.

It does not appear to be only the recent thread list data, because forcing the recent thread list calculation to return an empty list did not fix it.

The Android Samsung Internet result is notable: the same code-server UI and server worked much better there, while desktop Chromium browsers on Linux/Windows froze.

Request

Please investigate Codex IDE extension compatibility with code-server, especially:

  • Sidebar/webview initialization on desktop Chromium clients
  • ChatSession provider activation in VS Code-compatible web environments
  • Codex app-server IPC broadcast handling in code-server
  • Behavior when multiple extensionHost processes / workspaceStorage locks are created after reloads/freezes
  • Whether thread-stream-state-changed and related events can cause main-thread blocking or repeated webview work in code-server

Notes

The local extension bundle was modified for diagnostics only, with backups retained. The issue reproduced before those patches were applied.

View original on GitHub ↗

18 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #27892
  • #27023
  • #28280

Powered by Codex Action

SMOKE-19 · 1 month ago

Follow-up after testing the suggested duplicate/fix path:

I upgraded the code-server Codex extension to openai.chatgpt@26.609.30741 and verified that code-server is actually using that version:

code-server --list-extensions --show-versions
openai.chatgpt@26.609.30741

I also removed the old extension directories (26.527, 26.5609, 26.602) and cleared the stale workspaceStorage lock left by the old extension host, so there was no older Codex bundle left for code-server to load.

Unfortunately, the issue still reproduces on desktop Chromium-based browsers with code-server:

  • Open Codex sidebar
  • UI is responsive only briefly
  • code-server / browser UI freezes during sidebar initialization before opening a specific thread

Android Samsung Internet against the same code-server instance is still usable, so the problem still appears specific to the combination of code-server + desktop Chromium/Web VS Code runtime + Codex sidebar/webview initialization.

This means the workaround/fix noted in #27023 (26.609.30741) does not resolve this code-server case.

Dolyfin · 1 month ago

I wanted to get code-server working with Codex without having to wait for an update. I got Codex to debug the server and it did this to get it working:

Environment:

  • Raspberry Pi 5, aarch64
  • Debian GNU/Linux 13 trixie
  • code-server 4.125.0 with Code 1.125.0
  • code-server bundled Node v24.15.0
  • Codex extension openai.chatgpt@26.616.32156, linux-arm64
  • Bundled Codex CLI 0.142.0-alpha.1
  • Browser tested from Windows with Helium 144.0.7559.109

The failing log entry was:

PendingMigrationError: navigator is now a global in nodejs
    at get (file:///usr/lib/code-server/lib/vscode/out/vs/workbench/api/node/extensionHostProcess.js:837:7243)
    at ~/.local/share/code-server/extensions/openai.chatgpt-26.616.32156-linux-arm64/out/extension.js:1:10389

The local workaround was to patch the installed extension bundle:

~/.local/share/code-server/extensions/openai.chatgpt-26.616.32156-linux-arm64/out/extension.js

It replaced 4 direct checks of:

typeof navigator<"u"1

with: false

After killing stale extensionHost and Codex app-server processes, the PendingMigrationError stopped appearing and the Codex sidebar loaded to the sign-in screen instead of freezing the code-server page.

This is not a proper fix, just a local workaround. It looks like the extension is touching the global navigator from the Node extension host path, which breaks under code-server’s current runtime. There are still potential listener LEAK detected warnings in the browser console, plus a code-server CSP warning blocking a data: WOFF2 font.

It currently does indeed work until a proper fix comes out.

PS. Samsung internet on my zfold 6 also had freezing on the unpatched version.

SMOKE-19 · 29 days ago

Final follow-up after more local debugging:

I found a second issue that appears to be the main cause of the desktop browser freeze in my code-server setup.

Dolyfin's navigator finding was real and reproducible on my side too. Before patching the installed extension bundle, I also saw:

PendingMigrationError: navigator is now a global in nodejs

Replacing the direct typeof navigator < "u" checks in the installed extension bundle stopped that error. However, that was not enough to fix my freeze. The sidebar still froze on desktop Chromium / Edge clients.

The actual freeze in my environment was caused by the Codex webview preload path.

In openai.chatgpt@26.609.30741, the generated webview entry file:

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

loaded the main app with a very large Vite dependency preload list:

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

That caused the Codex sidebar webview to request hundreds of JS/CSS assets as soon as the sidebar iframe was mounted.

In code-server, those webview asset requests go through the browser/workbench resource bridge and extension file loading path. On desktop Chromium browsers, opening the Codex sidebar immediately produced browser console warnings like:

potential listener LEAK detected
doReadFileStream
readFileStream
loadResource

The code-server server log also showed repeated:

RequestStore#acceptReply was called without receiving a matching request

That matched the exact freeze point: immediately after opening the Codex sidebar, before opening a specific thread.

As a local workaround, I changed the generated webview entry so that only CSS chunks are preloaded and the large JS preload list is not eagerly loaded:

__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 the four static modulepreload links from webview/index.html.

With this workaround:

  • Windows / desktop Chromium no longer freezes when opening the Codex sidebar.
  • Android Samsung Internet still renders correctly.
  • Keeping no preload list at all avoided the desktop freeze but broke the Android UI because CSS chunks were not loaded early enough.
  • Keeping only the CSS preload list preserved the UI while avoiding the desktop freeze.

So the final local diagnosis is:

  1. There is likely a Node extension-host compatibility issue around navigator access under code-server.
  2. Separately, the hard freeze I originally reported appears to be caused by the Codex webview eagerly preloading hundreds of Vite chunks, which overwhelms or breaks code-server's webview resource loading path on desktop Chromium clients.

The original hypotheses about large local session history, recent thread list size, plugin catalog sync, and IPC broadcast noise were tested and did not fix the freeze.

I'm going to close this issue because I now have a local workaround and the root cause is much narrower than the original report. Hopefully this helps if you decide to make the Codex webview preload behavior more code-server-friendly.

SMOKE-19 · 29 days ago

Closing after identifying a local workaround and narrowing the root cause.

Dolyfin · 29 days ago

Please reopen the issue until a proper fix has been implemented rather than relying on self patches as a fix. I do not agree you should be closing issues when only possible causes are discovered.

SMOKE-19 · 29 days ago

Reopening this because the issue is not fixed upstream yet, and I agree with @Dolyfin that a local self-patch should not be treated as a proper resolution.

After further investigation, I now think this is best understood as a boundary issue between the Codex extension webview and code-server's webview/resource loading path, rather than a simple session-history or Codex data corruption issue.

The local workaround that made the freeze disappear was to reduce the Codex webview preload behavior:

  • changing the generated __vite__mapDeps([...]) dependency preload list to CSS-only entries
  • removing static modulepreload links from the installed webview index.html

This prevented the desktop Chromium/Edge code-server client from freezing when opening the Codex sidebar.

However, I do not think this should be considered a proper Codex-side fix. The triggering behavior may come from the Codex extension bundle, but the failure mode looks more fundamental on the code-server side:

  • opening a webview can produce a large burst of local webview resource loads
  • code-server routes these through its webview/resource bridge
  • desktop Chromium-based browsers appear to process this burst aggressively
  • code-server/workbench then emits logs such as:
potential listener LEAK detected
doReadFileStream
readFileStream
loadResource
RequestStore#acceptReply was called without receiving a matching request

In my environment, this leads to a full workbench freeze.

So my current understanding is:

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

This means Codex can probably mitigate the issue by reducing or changing its preload strategy, but a more fundamental fix may be needed in code-server so that one extension webview cannot freeze the whole workbench through a large preload/resource-load burst.

I also opened a code-server issue for that side of the boundary:

https://github.com/coder/code-server/issues/7867

I am reopening this issue to keep the Codex-side tracking visible, but my current view is that this should probably be coordinated with code-server rather than treated only as a Codex extension bug.

aformusatii · 28 days ago

@SMOKE-19 can you fix the issue, use best developer ever skill :)

I've been using code-server for about a year now, and the Codex extension keeps breaking from time to time. Seen one of the contributors saying that he didn't even know that codex extension is running via browser...

Would it be possible to extend the Codex regression test suite to include a code-server test? Maybe one of the contributors would be interested in taking this on, it should be relatively straightforward.
I'd do it myself, but I'm just not at a point in my life where I have the time for it.

Thanks so much to whoever takes this on.

aformusatii · 28 days ago
@SMOKE-19 can you fix the issue, use best developer ever skill :) I've been using code-server for about a year now, and the Codex extension keeps breaking from time to time. Seen one of the contributors saying that he didn't even know that codex extension is running via browser... Would it be possible to extend the Codex regression test suite to include a code-server test? Maybe one of the contributors would be interested in taking this on, it should be relatively straightforward. I'd do it myself, but I'm just not at a point in my life where I have the time for it. Thanks so much to whoever takes this on.

Meanwhile switching to claude code extension.

lksin · 26 days ago

I've been experiencing this issue across all 26.616 versions. Since rolling back to 26.506, I haven't hit the PendingMigrationError: navigator is now a global in Node.js error for over a week.

For anyone affected, the fastest workaround right now is to downgrade to 26.506 or use the Claude Code Extension instead. ;<

SMOKE-19 · 17 days ago

Codex Extension Local Patch Details

  • Date: 2026-07-03
  • Incident: code-server + Codex IDE extension webview preload freeze
  • Patch type: local self-patch, not an upstream fix
  • Actual patch target: the installed Codex VS Code extension bundle, not code-server itself

Conclusion

The patch that stopped the freeze was applied to the installed Codex extension bundle inside code-server. code-server itself was not modified.

Codex extension webview preload burst
→ code-server webview/resource bridge
→ desktop Chromium / Edge client
→ readFileStream / loadResource listener amplification
→ workbench freeze

The workaround reduces the first step, the Codex webview preload burst, so that code-server's resource loading bottleneck is not triggered.

Installed Extension Path

$HOME/.local/share/code-server/extensions/openai.chatgpt-26.609.30741-linux-x64

Important files:

out/extension.js
webview/index.html
webview/assets/index-CaOlcDW2.js

Backup files:

out/extension.js.bak-before-navigator-global-patch-20260621
out/extension.js.bak-before-ipc-broadcast-drop-20260621
webview/index.html.bak-before-disable-modulepreload-20260621
webview/assets/index-CaOlcDW2.js.bak-before-disable-vite-deps-preload-20260621

1. Primary Patch: Reduced Vite Dependency Preload

Patched file:

webview/assets/index-CaOlcDW2.js

Before the patch, the generated Vite preload list included almost every dependency index.

__vite__mapDeps([0,1,2,3,4,5,6,7,8,9,10,...,486])

The current patch removes JS chunk preloading and keeps only the CSS dependency indexes.

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

Why this shape was kept:

  • Removing all preload entries avoided the desktop freeze but broke Android UI/CSS rendering.
  • Keeping the full JS/CSS preload burst reproduced the desktop Chromium / Edge freeze.
  • Keeping CSS-only preload avoided the desktop freeze while preserving Android UI rendering.

2. Primary Patch: Removed Static Modulepreload Links

Patched file:

webview/index.html

Before the patch, index.html contained these static modulepreload links.

<link rel="modulepreload" crossorigin href="./assets/preload-helper-Chd9yIcd.js">
<link rel="modulepreload" crossorigin href="./assets/chunk-Bj-mKKzh.js">
<link rel="modulepreload" crossorigin href="./assets/isEqual-BBVxzjme.js">
<link rel="modulepreload" crossorigin href="./assets/src-BZEwW6Pk.js">

The current file keeps only the entry script.

<script type="module" crossorigin src="./assets/index-CaOlcDW2.js"></script>

This reduces the initial resource request burst when the webview mounts.

3. Separate Compatibility Patch: Bypassed Navigator Checks

Patched file:

out/extension.js

Dolyfin reported the following code-server extension host compatibility clue:

PendingMigrationError: navigator is now a global in nodejs

The original bundle had four occurrences of this minified pattern:

typeof navigator<"u"

The current file has zero occurrences. Those checks were forced toward the false path.

Important distinction:

  • This patch addressed a real code-server compatibility issue.
  • It was not the direct cause of the final desktop freeze.
  • The decisive freeze workaround was the webview preload reduction.

Verification Commands

Check the current webview preload state:

EXT="$HOME/.local/share/code-server/extensions/openai.chatgpt-26.609.30741-linux-x64"
rg -n -o '__vite__mapDeps\(\[[^]]*\]\)' "$EXT/webview/assets/index-"*.js
rg -n 'modulepreload|index-CaOlcDW2' "$EXT/webview/index.html"

Expected state:

__vite__mapDeps([48,94,136,137,166,189,202,210,232,264,315,320,329,384,387,421,469,484,485,486])
webview/index.html should not contain modulepreload links.
Only the entry script should remain.

Check the navigator patch:

EXT="$HOME/.local/share/code-server/extensions/openai.chatgpt-26.609.30741-linux-x64"
rg -o 'typeof navigator<"u"' "$EXT/out/extension.js" | wc -l
rg -o 'typeof navigator<"u"' "$EXT/out/extension.js.bak-before-navigator-global-patch-20260621" | wc -l

Expected state:

current extension.js: 0
backup before navigator patch: 4

Was code-server Modified?

No. code-server itself was not patched.

Not modified:

  • code-server package source
  • code-server workbench bundle
  • code-server webview/resource bridge code
  • code-server service override

So the patch should be understood as:

official fix: no
code-server patch: no
installed Codex extension local patch: yes

Update Caveat

When the Codex extension updates, these may change:

  • extension folder version
  • webview/assets/index-*.js filename
  • __vite__mapDeps([...]) dependency indexes
  • webview/index.html preload link structure
  • minified navigator check pattern in out/extension.js

If the freeze returns after an update, first find the new extension folder:

find "$HOME/.local/share/code-server/extensions" -maxdepth 1 -type d -name 'openai.chatgpt-*' -print

Then inspect these keywords in the new extension folder:

modulepreload
__vite__mapDeps
typeof navigator<"u"
potential listener LEAK
readFileStream
loadResource
RequestStore#acceptReply

Reverting the Local Patch

To revert the local patch, restore the backup files.

EXT="$HOME/.local/share/code-server/extensions/openai.chatgpt-26.609.30741-linux-x64"

cp "$EXT/webview/assets/index-CaOlcDW2.js.bak-before-disable-vite-deps-preload-20260621" \
   "$EXT/webview/assets/index-CaOlcDW2.js"

cp "$EXT/webview/index.html.bak-before-disable-modulepreload-20260621" \
   "$EXT/webview/index.html"

cp "$EXT/out/extension.js.bak-before-navigator-global-patch-20260621" \
   "$EXT/out/extension.js"

Reverting may bring back the desktop Chromium / Edge Codex sidebar freeze.

SMOKE-19 · 17 days ago

I want to update my earlier interpretation based on the local patch results.

The issue still does not look like ordinary code-server instability, because code-server works normally until the Codex sidebar/webview path is activated, and removing the Codex extension avoids the freeze.

However, the strongest signal now points more specifically to Codex webview startup resource loading, rather than app-server/IPC or session data. The workaround that stopped the desktop Chromium / Edge freeze was reducing the Codex webview’s initial Vite/modulepreload burst:

removing static modulepreload links from webview/index.html
reducing the generated __vite__mapDeps([...]) dependency preload list in the webview bundle
keeping only the CSS-related preload entries so the UI still renders correctly

So my updated hypothesis is:

Codex webview initial preload burst
→ code-server webview/resource bridge bottleneck
→ desktop Chromium / Edge client freezes during sidebar initialization

The earlier app-server, IPC broadcast, ChatSession provider, session-history, and recent-thread-list diagnostics are still useful negative results, but they no longer look like the primary cause. The most likely Codex-side fix would be to make the webview startup less aggressive in code-server / VS Code web-like runtimes, for example by reducing modulepreload usage and lazy-loading heavier JS chunks after the sidebar becomes interactive.

SuperRonanCraft · 13 days ago

When will we get this patch? Haven't been able to use Codex for weeks using the github codespace cause this codex extension keeps freezing my chrome machine

nevdullcode · 13 days ago
When will we get this patch? Haven't been able to use Codex for weeks using the github codespace cause this codex extension keeps freezing my chrome machine

This doesn't answer your question, but, as @lksin mentioned, prior to opening Codex within the IDE, you can downgrade the installed Codex extension to 26.506.31421. See where to click the drop-down arrow and find "Install Specific Version..." in the screenshot below.

<img width="1629" height="316" alt="Image" src="https://github.com/user-attachments/assets/fbdc6c1b-f6ca-4219-876d-a93c61a8d772" />

I can confirm doing that enabled Codex in IDE to work for me.

webysther · 10 days ago
> When will we get this patch? Haven't been able to use Codex for weeks using the github codespace cause this codex extension keeps freezing my chrome machine This doesn't answer your question, but, as @lksin mentioned, prior to opening Codex within the IDE, you can downgrade the installed Codex extension to 26.506.31421. See where to click the drop-down arrow and find "Install Specific Version..." in the screenshot below. <img alt="Image" width="1629" height="316" src="https://private-user-images.githubusercontent.com/3473018/618438905-fbdc6c1b-f6ca-4219-876d-a93c61a8d772.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODM3MjU2MzIsIm5iZiI6MTc4MzcyNTMzMiwicGF0aCI6Ii8zNDczMDE4LzYxODQzODkwNS1mYmRjNmMxYi1mNmNhLTQyMTktODc2ZC1hOTNjNjFhOGQ3NzIucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI2MDcxMCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNjA3MTBUMjMxNTMyWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9ZmQ4NTJjZjFmYzdiNWFmYTc3NTQ3NTI3MmY1NDkzNDgwMTQzMDNjYWVkMDNkMTY0ZmUyN2IzNGU5ODI1ZjdlMCZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmcmVzcG9uc2UtY29udGVudC10eXBlPWltYWdlJTJGcG5nIn0.cztUWKSVS9QzANWN9tbWsw5T6P7oyTq0g9CjUHaEEWE"> I can confirm doing that enabled Codex in IDE to work for me.

confirmed in my instalation after downgrade works.

code-server:4.127.0

verzunov · 1 day ago

I can reproduce this issue on a Xiaomi Pad 7 running Android.

Environment:

  • code-server 4.121.0
  • VS Code base 1.121.0
  • OpenAI Codex extension 26.707.91948
  • Also reproduced with 26.715.31925
  • "extensions.supportNodeGlobalNavigator": true
  • Tested in Chrome, Edge, and other Android browsers

Control test:

  • Explorer works
  • editor and terminal work
  • Markdown Preview works without freezing
  • the freeze begins specifically when the Codex sidebar is opened

Chrome DevTools shows the same resource-loading amplification described in this issue:

  • potential listener LEAK detected
  • listener count grows: 175 → 263 → 351 → 439 → 527 → 615
  • stack includes doReadFileStream, readFileStream, and loadResource
  • unacknowledgedMsgCount: 248
  • Extension host (Remote) is unresponsive
  • Management and ExtensionHost WebSocket reconnect loops
  • WebSocket handshake timeout / Time limit reached

Clearing site data restores code-server temporarily, but opening Codex reproduces the freeze.

This strongly matches the large Codex Vite/modulepreload burst and code-server webview resource bridge issue identified above.

I can test a patched or pre-release extension on the same Xiaomi Pad 7.

verzunov · 1 day ago

Update: downgrading the Codex extension in code-server to
openai.chatgpt@26.506.31421 fixed the issue.

The Codex sidebar now works both in the laptop browser and on the
Xiaomi Pad 7 Android tablet.

Newer versions 26.707.91948 and 26.715.31925 reproduced the listener
leak and extension-host reconnect loop in code-server.

verzunov · 1 day ago

Update: I confirmed a working local workaround for
openai.chatgpt@26.715.31925.

I removed the two static modulepreload links and converted all 2008
__vite__mapDeps calls across 31 webview JS files to CSS-only preload
lists.

Results:

  • dependency preload references: 33196 → 515
  • largest preload burst: 1539 → 28
  • laptop Chromium: works
  • Xiaomi Pad 7 Android: works
  • GPT-5.6 Sol and the new model picker work
  • no extension-host reconnect loop observed

JavaScript chunks were not removed; they load normally on demand.
The bundled Codex CLI, app-server, and model picker were not modified.