VS Code Codex panel intermittently stuck loading on Linux: local webview assets fail with net::ERR_FAILED

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

• #32475

Powered by Codex Action

I think I have the same issue: "The Codex sidebar intermittently remains stuck on its loading logo" on Linux.

Same issue here

~ code --version
1.128.0
fc3def6774c76082adf699d366f31a557ce5573f
x64

~ code --list-extensions --show-versions |   grep -E '^openai\.chatgpt@'
openai.chatgpt@26.707.31428

Clearing the codex cache and switching to an older version (openai.chatgpt@26.623.101652) worked for me

I reproduced this on Fedora Linux 44 (Wayland, x86_64) with:

• VS Code 1.128.0 (fc3def6774c76082adf699d366f31a557ce5573f)
• Codex extension 26.707.41301

I instrumented the actual child active-frame of the Codex webview through the Chrome DevTools Protocol, rather than using extension activation as the pass/fail signal.

Exact failure

On a failed launch, the child frame remains at the static startup loader:

#root
  .startup-loader
    .startup-loader__logo

The Codex app-server still starts and responds to initialize, but React never replaces the loader. An instrumented webview reload captured this exception:

Error: Unable to preload CSS for
.../webview/assets/cmdk-uRuhKLE-.css
    at .../preload-helper-CQB7nEpd.js:1:976

At the same time, dozens of bundled JS and CSS resources fail with net::ERR_FAILED, including:

google-chrome-BHSzyoHT.js
browser-sidebar-webview-NDgmoRyT.js
app-server-connection-state-presentation-CnBDAkF7.js
thread-layout-Br0qrzk4.js
cmdk-uRuhKLE-.css

The extension host then reports:

View has not been initialized after retrying for 5 seconds.

What I ruled out

• The failed files are present and valid on disk.
• Fetching the same failed assets sequentially from inside the failed webview returns HTTP 200 with the correct byte counts in 2-9 ms.
• Clearing CacheStorage is not reliable.
• Removing stale resources from the previous Codex version is not reliable.
• Rotating the persisted VS Code webview origin is not reliable.
• Reinstalling the extension only helps temporarily.
• The listener-leak warning also occurs on successful launches, so it is a pressure indicator rather than a reliable failure signal.

The VS Code service-worker cache contained 735 current-version Codex resources and 720 resources from the previous extension version. VS Code revalidates cached webview resources through the host, so the cache does not eliminate the request fan-out.

A direct 735-resource parallel-fetch probe produced two useful control results:

Failed real-profile webview: 0/735 succeeded; all returned HTTP 408 after 30 seconds
Loaded isolated-profile webview: 735/735 succeeded in 1.16 seconds

This suggests that the large preload fan-out exposes an intermittent VS Code webview resource-bridge failure, but fan-out alone is not deterministic.

Secondary Linux resource issue

During one hard-hang reproduction, Codex also logged:

failed to initialize skills file watcher: No file descriptors available (os error 24)
filesystem watch manager falling back to noop core watcher: No file descriptors available (os error 24)

The per-user inotify instance quota was exactly exhausted (128/128). Raising fs.inotify.max_user_instances to 1024 removes this secondary failure, but the startup spinner still reproduced with only 67/128 instances in use. It is therefore an amplifier, not the sole cause.

Verified Codex-side mitigation

The generated preload-helper-CQB7nEpd.js synchronously creates preload links for every JS and CSS dependency passed to it. I locally changed only this helper to:

1. Skip optional JavaScript modulepreload links. The real import() still loads all application modules.
2. Queue CSS preloads with a maximum concurrency of four.
3. Attach CSS load/error handlers before appending the link.

No authentication, app-server, API, or application logic was changed.

Verification against the same real profile and normal desktop startup path:

Unpatched: failed on cold-start loop run 2
Patched:   10/10 cold starts loaded successfully
Final normal launch: app routes mounted after 2876 ms

The Codex-side fixes I would recommend are:

• Bound or remove speculative JS modulepreload fan-out in the VS Code webview build.
• Bound CSS preload concurrency.
• Replace the permanent startup loader with a retry/error state when vite:preloadError fires.

The current behavior turns one transient local-resource failure into an unrecoverable infinite spinner with no visible error.

Same thing with 26.707.71524 (VS Code 1.128.1)

System:
Kernel: 7.1.3-1-default arch: x86_64 bits: 64
Desktop: KDE Plasma v: 6.7.2 (Wayland)
Distro: openSUSE Tumbleweed 20260714

I can reproduce the same webview resource-load failure on a different path: the Codex Settings panel, not just the main sidebar.

Environment

• Client: Windows 11 x64 (Windows_NT 10.0.26200)
• VS Code: 1.128.1, commit 5264f2156cbcd7aea5fd004d29eaa10209155d66, Electron 42.5.0
• Connection: VS Code Remote-SSH to a Linux host; the extension is installed and runs on the remote host
• Extension: openai.chatgpt-26.707.71524-linux-x64

Settings-specific trigger

The main Codex sidebar can be usable, but opening the profile-menu gear / Codex Settings creates a separate custom WebviewPanel that frequently remains on the centered Codex logo for a long time. VS Code also shows its yellow "window is not responding" prompt. On some attempts the Settings page eventually renders without any configuration change, which points to a resource-loading stall rather than permanently invalid Settings state.

The bundled app-server starts and initializes; this failure occurs before the Settings webview completes normal frontend bootstrap.

DevTools evidence

The VS Code renderer DevTools repeatedly reported:

potential listener LEAK detected, having 263 listeners already.
MOST frequent listener (89):

CancellationTokenSource
  -> FileService.doReadFileStream
  -> FileService.readFileStream
  -> loadLocalResource
  -> WebviewElement.loadResource

The corresponding stack originates from the vscode-webview://... frame for extensionId=openai.chatgpt and its postMessage resource-loading path.

There is also a separate CSP error for an embedded data:font/woff2 font (font-src 'self' https://*.vscode-cdn.net). It appears to be a packaging/CSP defect, but the main sidebar can render with the same stylesheet, so I do not think it is the primary cause of the stall.

Why Settings makes the failure much easier to trigger

I inspected the installed Settings route bundle. Its lazy import passes 174 dependencies to the generated Vite preload helper. That helper synchronously appends a preload link for every dependency before resolving the import. In a Remote-SSH window, each local extension asset travels through the VS Code webview resource bridge, matching the readFileStream -> loadLocalResource -> loadResource stack above.

This looks consistent with the bounded-concurrency / reduced-speculative-preload mitigation described in the preceding comment. It is not an app-server crash or an authentication failure.

No remote hostname, user path, workspace name, session content, or credentials are included here.

I add this problem, And after a lot of troubleshooting, I found out that the codex extension has more than 4k .js files on webview/assets
$HOME/.vscode/extensions/openai.chatgpt-<version>-linux-x64/webview/assets

it solved with ulimit -n 10000.

try this pkill -9 code; pkill -9 Code; ulimit -n 10000; code --new-window
if doesn't work try a higher value.

if it works use. to make it permanent.

mkdir -p ~/.config/systemd/user.conf.d
nano ~/.config/systemd/user.conf.d/limits.conf

[Manager]
DefaultLimitNOFILE=10000

then reboot the machine.

Deterministic confirmation on Kubuntu 26.04 KDE Wayland, VS Code 1.129.1 (8a7abeba6e03ea3af87bfbce9a1b7e48fed567b8), Codex extension 26.715.31925.

The graphical session has the documented systemd RLIMIT_NOFILE default of soft 1024 / hard 524288. A direct /usr/share/code/code launch gives zygotes/renderers a soft limit of 1024. Codex then fails after the listener count increases from 175 to 615, followed by:

FetchEvent ... insufficient resources
net::ERR_FAILED

for Codex webview JavaScript and CSS assets.

The failure is caused by the Codex webview’s thousands of chunks/resource requests exhausting the low-limit renderer during its startup burst. The client-status-changed warning is incidental.

I also traced the VS Code startup ordering:

03:58:55.721 zygote A execs with soft limit 1024
03:58:55.723 zygote B execs with soft limit 1024
03:58:55.803 browser main raises itself 1024 → 8192
03:58:55.812 Node raises browser main 8192 → 524288

Renderers fork from the already-created 1024-limit zygotes, so the later changes to the browser process do not affect them.

Two confirmed workarounds:

Fully exit every VS Code process, verify pgrep -x code produces no output, then launch the official deb build through its CLI bootstrap:

code

The CLI runs the binary in Node mode first. Node raises the limit to 524288 before starting graphical Electron, so the zygotes/renderers inherit the higher value. This will not help if code merely connects to an already-running low-limit instance.

Start graphical VS Code with an explicit per-application limit:

(ulimit -Sn 65536 && exec /usr/share/code/code)

This worked consistently. For a graphical launcher, the equivalent command is:

/usr/bin/prlimit --nofile=65536:524288 -- /usr/share/code/code %F

Running the direct launch under strace also makes Codex work while the renderers remain at 1024, confirming that slowing the startup burst reduces peak resource concurrency rather than changing the limit.

Please reduce/bundle the number of webview chunks and lazy-load or cap concurrent resource loading. The extension should not depend on unusually high renderer FD limits to boot successfully.

https://github.com/openai/codex/issues/32530#issuecomment-5012908167
This worked perfectly for me! Thanks @a-bentofreire
I am able to consistently get it working with ulimit -n 10000

Yes, can confirm the ulimit issue. That also explains why this https://github.com/openai/codex/issues/33108#issuecomment-4977999621 workaround works. /usr/share/code starts vs code with hard limit, not soft.

Yes, can confirm the ulimit issue. That also explains why this #33108 (comment) workaround works. /usr/share/code starts vs code with hard limit, not soft.

on linux, processes have soft and hard limit.. they can raise their soft limit.. the problem is /usr/share/code will launch chrome that will raise the limit for the process, but after the extensions have been loaded (which inherit the unraised soft limit of 1024)

when code is run, it starts node first which increases the soft limit before running /usr/share/code, so it will unblock the file read burst