Ubuntu 24.04, VS Code 1.125.1, Codex 26.616.51431. failed to load codex chat ...

Additional verified diagnostics

Environment

• Ubuntu 24.04 x86_64
• VS Code 1.125.1
• Codex extension openai.chatgpt@26.616.51431
• Bundled CLI codex-cli 0.142.0-alpha.6
• Soft/hard RLIMIT_NOFILE: 1024 / 1048576
• Files directly under the extension's webview/assets directory: 1410

Observed failure

The Codex backend was healthy: codex app-server remained running, authentication was valid, and codex doctor reported working WebSocket connectivity. The sidebar stayed on the static petal/terminal startup loader because its module graph did not finish loading.

Chrome DevTools Protocol inspection of the Codex webview captured this uncaught exception:

Error: Unable to preload CSS for
.../webview/assets/thinking-shimmer-83dxNCp_.css
    at HTMLLinkElement.<anonymous>
    (.../webview/assets/preload-helper-2ej06EnG.js:1:918)

Dozens of existing, readable local assets failed concurrently, including JS and CSS files:

Failed to load resource: net::ERR_FAILED
https://file+.vscode-resource.vscode-cdn.net/.../webview/assets/hooks-BsGNxXIG.js
https://file+.vscode-resource.vscode-cdn.net/.../webview/assets/app-main-BWYQnX6b.css
https://file+.vscode-resource.vscode-cdn.net/.../webview/assets/thinking-shimmer-83dxNCp_.css

At the same time, VS Code's renderer log reported:

potential listener LEAK detected
  at ...doReadFileStream
  at ...readFileStream
  at async ...loadResource

The files existed, were owned by the user, had mode 0644, and were on a normal local ext4 filesystem. This was not a missing-file, extension-signature, OAuth, network-connectivity, or Codex app-server problem.

Controlled comparison

With the unmodified extension and the inherited soft limit of 1024, repeated clean-profile launches remained on the startup loader and never logged app routes mounted.

Launching the same VS Code and extension builds with:

ulimit -n 65536
exec /usr/share/code/code "$@"

caused the main and extension-host processes to inherit 65536 / 65536. The same clean-profile test then succeeded consistently and logged:

[startup][renderer] app routes mounted after 4508ms

Suggested fix

Please avoid eagerly preloading enough webview chunks to exhaust a common Linux desktop soft file-descriptor limit of 1024. Limiting asset-load concurrency, reducing the generated chunk/preload count, and handling preload failures without aborting application startup would make the extension robust without requiring users to modify their VS Code launcher.

I can reproduce the same failure on a current Linux build even though VS Code's inherited open-file limit is 1,073,741,816, so this does not appear to require the 1,024 FD limit described in the original report.

Environment:

• Codex IDE extension: 26.707.41301 (linux-x64)
• VS Code: 1.128.0
• Platform: Linux 6.14.0-37-generic x86_64
• Bundled CLI: codex-cli 0.144.0-alpha.4
• VS Code Max open files: soft/hard 1073741816

Symptoms and diagnostics:

• The Codex panel remains forever on the petal/startup loader (sometimes it becomes gray).
• The extension host successfully activates, spawns codex app-server, receives initialize request id=1, and establishes its HTTPS connection. The backend is healthy.
• The webview service worker repeatedly reports:

NetworkError: Failed to execute 'put' on 'Cache': Cache.put() encountered a network error

• DevTools shows many local file+.vscode-resource.vscode-cdn.net assets failing with net::ERR_FAILED.
• The first failed asset changes between runs. One representative exception is:

Error: Unable to preload CSS for .../generated-image-preview-Dzsr8GQ_.css

• Fetching each failed asset individually returns HTTP 200, so files are present and readable.
• Clearing WebStorage, Service Worker, Cache, Code Cache, and GPUCache does not fix the unmodified extension.
• The regression returned immediately when the extension auto-updated from 26.707.31123 to 26.707.41301, because the update replaced the workaround below.

Confirmed workaround:

In webview/assets/preload-helper-CQB7nEpd.js, retain CSS preload links but skip eager JavaScript modulepreload links:

let isCss = url.endsWith(".css");
if (!isCss) return;

JavaScript still loads through normal ES module imports. After this one-line behavioral change and a webview-cache reset, the complete Tasks/composer UI mounts reliably and the startup loader disappears. The same workaround has fixed two consecutive extension builds here (26.707.31123 and 26.707.41301).

This suggests the large eager preload burst itself can overwhelm or race VS Code's webview/service-worker resource transport independently of the process FD limit. Reducing/limiting JS preloads, or making CSS preload failures non-fatal, would make startup robust.

Same issue reproducing for me also.
Couple of days back i installed fresh ubuntu 24.
I tried installing codex extension in VSCode, after installing it results in loading screen and won't allow us to login/use.

Please fix this issue soon 🙏

@qjdykhvftb-ops @etegan I have a solution guys. Open your repo folder/workspace from ubuntu terminal. It works.
Thank me later.

setting a higher ulimit fixes for me, ubuntu 26.04, but still annoying as heck to diagnose this.