Codex stuck on loading/logo screen in the sidebar

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

• #26098
• #25716

Powered by Codex Action

I was facing the same issue in VS Code where the Codex sidebar/chat panel was getting stuck on the logo/loading screen after opening. In my case, the issue was most likely caused by a conflict with another AI-related VS Code extension.

After checking my extensions, I disabled other AI assistant extensions, especially Amazon Q, and then restarted VS Code. After disabling that conflicting extension, the Codex chat panel started working properly again.

Possible fix:

Open VS Code Extensions panel.
Disable other AI/chat assistant extensions temporarily, such as Amazon Q or similar tools.
Restart VS Code.
Open the Codex sidebar/chat panel again.

This worked for me, so the issue may be related to an extension conflict rather than Codex itself. It may be helpful to test Codex with only the required extension enabled.

Root cause found (Linux): renderer hits the default 1024 open-file limit while loading ~5000 webview chunks

TL;DR: On Linux desktops, VS Code's renderer process inherits the session's default soft file-descriptor limit (ulimit -n = 1024). The Codex extension's webview now ships ~4,900 asset chunks (webview/assets/, v26.5707.31428) that are fetched in a large concurrent burst at startup. Once the fd budget is exhausted, the webview service worker rejects every remaining request with a network error, the app bundle never executes, and the sidebar sits forever on the static startup-loader logo — with no user-visible error. Raising the limit fixes it instantly.

Environment

• Ubuntu 26.04, VS Code 1.128.0 (deb, launched from the desktop session)
• Codex extension 26.5707.31428 (pre-release) — stable 26.707.x shows identical behavior
• Codex CLI works fine on the same machine (same ~/.codex, same auth)

Symptoms (matches this issue, #7150, #15975, #11046)

• Sidebar stuck on the Codex logo / loading screen indefinitely
• No errors in Output → Codex; extension host log stops after [CodexMcpConnection] Initialize received id=1
• Keyboard shortcuts (even Ctrl+Shift+P) stop working while the Codex view has focus (the dead webview swallows key events)
• Reinstalling, switching stable/pre-release, clearing caches, re-auth: no effect

Diagnosis

Everything backend-side was verified healthy by driving the bundled binary manually (codex app-server + JSON-RPC: initialize, account/read, model/list, thread/list, thread/start incl. the responses_websocket transport — all instant).

Webview DevTools console showed the smoking gun — hundreds of:

The FetchEvent for "<URL>" resulted in a network error response: insufficient resources.
...webview/assets/<chunk>.js:1  Failed to load resource: net::ERR_FAILED

Process limits confirmed it (/proc/<pid>/limits):

| VS Code process | Max open files (soft) |
|---|---|
| main / utility (network, exthost) | 524288 |
| gpu-process | 16384 |
| zygote / renderer (runs webviews) | 1024 |

webview/assets/ in 26.5707.31428 contains 4,936 files; the startup import graph requests thousands of them concurrently through the webview service worker → net::ERR_INSUFFICIENT_RESOURCES once the renderer runs out of descriptors.

This also explains why the regression appeared "out of nowhere" for users: the chunk count has grown across releases, and each install starts failing once it crosses the ~1024 budget of a default Linux desktop session — independent of the extension version being (re)installed.

Workaround for affected users (Linux)

Immediate test:

# fully quit VS Code first
ulimit -n 65536 && code

Permanent (no root needed), covers launches from the dock/launcher after re-login:

# ~/.config/systemd/user.conf
[Manager]
DefaultLimitNOFILE=65536:524288

Verified: with the raised limit the sidebar loads instantly; with 1024 it reproduces 100% of the time.

Suggestions for the maintainers

1. Cap the concurrency of the initial chunk prefetch (or consolidate the ~5k-file bundle) so the webview stays within a 1024-fd budget — this is the default on most Linux distros, so a large share of Linux users are affected.
2. Fail loudly: if the app bundle fails to boot, replace the infinite startup loader with an error screen. Today this failure mode is completely silent, which is why the linked issues have gone undiagnosed for months.
3. Consider documenting the ulimit requirement for Linux until then.

Confirmed on Ubuntu 24.04: desktop launcher limit causes a 100% startup failure

I independently reproduced and diagnosed this on:

• Ubuntu 24.04 Desktop
• VS Code 1.128.0 (.deb installation)
• OpenAI Codex extension 26.707.41301

Controlled results

| Launch method | Renderer Max open files | Codex result |
| --- | ---: | --- |
| Normal application icon | 1024 soft | 0/5 successful; stuck on the ChatGPT/Codex logo every time |
| ulimit -n 65536; code --new-window | raised | 5/5 successful |
| User-level desktop launcher wrapper | 65536 soft/hard | 5/5 successful |

The Codex web app and Codex CLI continued to work while the VS Code extension was stuck, so this was not an account, authentication, network, or backend outage.

Direct evidence from the failed webview

The VS Code webview threw:

SyntaxError: Unexpected end of input

for this startup chunk:

thread-side-panel-tab-content-DymGX7fa.js

The file on disk was valid and complete:

size:   334263 bytes
sha256: 397b6c23c75644f681aee2cedcddd7e3e9afc6fd53fa91deb7f39c34532d9853
node --check: passed

The response stored by the VS Code webview service worker in vscode-resource-cache-5 was truncated mid-token:

size:   262144 bytes (exactly 256 KiB)
sha256: 0b252410c0441dd19ef4a283654d892ab788a89caf8df076f69ed02b04b6f9ea

VS Code's workbench console also reported potential listener LEAK from fileService.readFileStream / webview resource loading. Clearing Local Storage, Session Storage, Service Worker, and WebStorage did not fix the problem: the bad resource state was regenerated immediately while the renderer limit remained 1024.

Immediate workaround

Fully quit VS Code, then launch it from a terminal:

ulimit -n 65536
code --new-window

Tested user-level desktop launcher workaround (.deb install)

Create ~/.local/bin/code-high-nofile:

#!/bin/sh
ulimit -n 65536
exec /usr/share/code/code "$@"

Make it executable:

chmod 755 ~/.local/bin/code-high-nofile

Copy /usr/share/applications/code.desktop to ~/.local/share/applications/code.desktop, then change both Exec= entries to:

Exec=/home/YOUR_USER/.local/bin/code-high-nofile %F

and for the new-empty-window desktop action:

Exec=/home/YOUR_USER/.local/bin/code-high-nofile --new-window %F

Finally refresh the user desktop database:

update-desktop-database ~/.local/share/applications

After this change, every VS Code main, zygote, renderer, GPU, and utility process had a 65536 soft/hard open-file limit, and the Codex sidebar opened successfully in all five repeated tests from the normal application icon.

This confirms the failure is deterministic for this environment and that raising the renderer's inherited file-descriptor limit resolves it. A product-side fix should still throttle/consolidate the initial webview resource burst, raise the renderer limit, and show a visible bootstrap error instead of leaving the user on an infinite logo screen.

@maolibu Man, you are our savior. This problem surfaced a few months ago and it was getting progressively worse, to the point that I couldn't load the extension at all. I suspect it's vibe coded and the devs don't even know what's going on; probably no human reads these issues either. We are on our own. It's grim really.
Your settings totally work, except the user.conf hack does nothing on my Ubuntu 24.04. Here is the snippet (thanks ChatGPT) that did the job permanently (sudo + reboot required):

```# 1. systemd system manager defaults:

affects system services such as ssh.service, getty@.service, display managers, etc.

sudo install -d -m 0755 /etc/systemd/system.conf.d

sudo tee /etc/systemd/system.conf.d/90-nofile.conf >/dev/null <<'EOF'
[Manager]
DefaultLimitNOFILE=65535:524288
EOF

2. Raise the per-user systemd manager itself:

affects systemd --user managers started as user@UID.service

sudo install -d -m 0755 /etc/systemd/system/user@.service.d

sudo tee /etc/systemd/system/user@.service.d/90-nofile.conf >/dev/null <<'EOF'
[Service]
LimitNOFILE=65535:524288
EOF

3. Defaults for units started by systemd --user:

sudo install -d -m 0755 /etc/systemd/user.conf.d

sudo tee /etc/systemd/user.conf.d/90-nofile.conf >/dev/null <<'EOF'
[Manager]
DefaultLimitNOFILE=65535:524288
EOF

4. PAM login sessions:

affects login shells where pam_limits.so is used: ssh, login, sudo/su depending on PAM config

sudo install -d -m 0755 /etc/security/limits.d

sudo tee /etc/security/limits.d/90-nofile.conf >/dev/null <<'EOF'

• soft nofile 65535
• hard nofile 524288

root soft nofile 65535
root hard nofile 524288
EOF

can confirm this fixed it for me. ulimit -n 65536 works. Am running ubuntu 26.04 and was getting this problem.

edit: nevermind, didnt work. Codex for vscode on Linux is completely broken. really annoying.