← All posts

How I Fixed the OpenAI Codex Extension Freezing in Browser-Based code-server

July 18, 2026·#codex#code-server#vscode#debugging#webview#self-hosting

A tested step-by-step workaround for the Codex loading-logo freeze, pending JavaScript request flood, and readFileStream listener leak in code-server.

How I Fixed the OpenAI Codex Extension Freezing in Browser-Based code-server

The OpenAI Codex extension installed successfully in my browser-based code-server environment. The Codex backend also started, but the sidebar remained stuck on its loading logo and sometimes made the entire browser tab unresponsive.

After checking the Linux service, IPC permissions, temporary directories, authentication, NGINX, HTTPS, Cloudflare Tunnel, and finally a static public IP, I confirmed that the network was not the root cause.

The actual failure was a browser webview resource flood.

Important: This is an unofficial community workaround. It modifies generated frontend files inside the installed Codex extension. Back up the extension first and keep auto-update disabled while using the patch.

Video walkthrough

A companion YouTube walkthrough is planned. When the video is published, this section will be updated with the final YouTube link.

What the failure looked like

Chrome DevTools showed hundreds of Codex JavaScript files stuck in Pending state. Many were initiated through about:client1. The console repeatedly reported:

potential listener LEAK detected
doReadFileStream
readFileStream
loadResource

Meanwhile, the Codex CLI and codex app-server continued to run. This proved the subscription, sign-in, and backend were healthy.

The real cause

The Codex webview bundle was eagerly preloading hundreds or thousands of Vite-generated JavaScript dependencies. Browser-based code-server serves extension webview resources through a Service Worker and internal resource bridge.

Under the large startup burst, that resource path accumulated listeners and left hundreds of requests pending. Chromium eventually became slow or froze completely.

In the tested extension build, the diagnostic dry-run found:

JavaScript files requiring changes: 13
Large preload calls requiring changes: 79

One generated dependency list attempted to preload more than 1,500 assets.

What fixed it

The fix was to:

  1. Find every unusually large __vite__mapDeps([...]) preload call.
  2. Keep only its CSS dependencies in the preload list.
  3. Remove static modulepreload links from the webview HTML.
  4. Allow JavaScript chunks to load normally when the application imports them.
  5. Clear the existing browser Service Worker and cached site data.

This removed the startup request storm while preserving the Codex interface styling.

Step-by-step fix

1. Turn off Codex extension auto-update

Open the extension page and disable Auto Update. Updates replace the modified bundle.

2. Locate the extension

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

Set the exact result:

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

3. Back it up outside the extension directory

BACKUP_ROOT="$HOME/.local/share/code-server/extension-backups"
mkdir -p "$BACKUP_ROOT"
BACKUP="$BACKUP_ROOT/$(basename "$EXT")-$(date +%Y%m%d-%H%M%S)"
cp -a -- "$EXT" "$BACKUP"
test -d "$BACKUP" && echo "Backup OK: $BACKUP"

4. Obtain the patch script

Copy the accompanying patch-codex-webview.js file to:

/tmp/patch-codex-webview.js

5. Run a dry-run

node /tmp/patch-codex-webview.js "$EXT"

Review the detected files and preload counts. Do not continue if it reports an invalid directory or dependency-map parsing error.

6. Apply

node /tmp/patch-codex-webview.js "$EXT" --apply

If root applied it for another account:

chown -R username:username "$EXT"

Restart code-server:

sudo systemctl restart code-server@username

7. Clear stale browser data

Close every code-server tab, remove the hostname from browser site data, completely exit the browser, and reopen only one tab.

If Cloudflare or another CDN fronts code-server, purge the hostname and bypass caching for the application. Because the patch changes existing hashed files without renaming them, stale cache entries can otherwise serve the original broken JavaScript.

Result

After applying the patch and clearing browser state:

  • Codex rendered successfully.
  • The composer became usable.
  • Existing chats appeared.
  • The browser stopped freezing.
  • The huge pending request burst disappeared.

Rollback

If anything breaks:

sudo systemctl stop code-server@username
mv -- "$EXT" "${EXT}.patched-failed"
cp -a -- "$BACKUP" "$EXT"
chown -R username:username "$EXT"
sudo systemctl start code-server@username

Clear the browser site data once more after restoring.

Important limitations

This is a workaround, not a permanent upstream fix. Every extension release may change the generated bundle. After an update, first test the new version without modification. Reapply only if the same pending-request and listener-leak pattern returns and the patcher's dry-run recognizes it.

For a fully supported alternative, use Codex CLI or the Codex extension inside desktop VS Code.

References

This guide documents a real-world fix tested by Maalig / 6D Ai NAS India on Ubuntu 24.04, code-server 4.129.0, and Codex extension 26.715.31925.