How I Fixed the OpenAI Codex Extension Freezing in Browser-Based code-server
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:
- Find every unusually large
__vite__mapDeps([...])preload call. - Keep only its CSS dependencies in the preload list.
- Remove static
modulepreloadlinks from the webview HTML. - Allow JavaScript chunks to load normally when the application imports them.
- 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.