Linux - Codex VS code extension stuck in loading.

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

• #33059

Powered by Codex Action

https://github.com/openai/codex/issues/30576#issuecomment-4940021663
Follow-up: I've found two reliable workarounds for my situation: link above.

1. If I start VS Code with code --disable-gpu , the Codex extension will reliably load and never hang.
2. Of course, disabling GPU is not desirable. Through trial & error I found out that the issue in my case is path-resolution behavior in VS Code, not extension contents, GPU, authentication, or Codex configuration. If I start VS Code using the default settings, it's freezing up. However, if I specify the exact same extensions folder explicitly with code --extensions-dir "$HOME/.vscode/extensions", then the freezing behaviour will be gone reliably.

I have exactly same issue on Linux AMD64 env.
ae-buddy's solution worked for me.

set ulimit -n 10000
https://github.com/openai/codex/issues/32530#issuecomment-5012908167
This worked consistently for me

Codex help diagnose my VS Code extension issues as:

VS Code Version: 1.129.1
Commit: 8a7abeba6e03ea3af87bfbce9a1b7e48fed567b8
Date: 2026-07-17T15:35:09Z
Electron: 42.6.0
ElectronBuildId: 14623276
Chromium: 148.0.7778.280
Node.js: 24.18.0
V8: 14.8.178.38-electron.0
OS: Linux x64 7.0.11-76070011-generic

Root cause: Codex 26.715.31925 loads a 456,486-byte JavaScript module, but VS Code intermittently serves only the
  first 262,144 bytes. That produces a syntax error and leaves the sidebar blank. VS Code 1.128 and 1.129 both
  reproduced it.

  - Downgraded Codex to 26.506.21252.
  - Temporarily pinned only openai.chatgpt in extensions.donotAutoUpdate; all other extensions still update.

Why the downgrade worked:

  - The latest build contains a valid 456,486-byte JavaScript module.
  - VS Code intermittently delivered only exactly 262,144 bytes of it to the Codex webview.
  - The truncated file caused SyntaxError: Private field '#r' must be declared... before React could render, producing
    the blank panel.

  - 26.506.21252 uses a different compiled-module layout and loading order. It avoids that startup-critical failure on
    your machine.

NOTE - This doesn't allow you to run the latest version of Codex. I ended up not opting to run an old version and instead found success through issue #34308.

Additional data from an identical environment (NVIDIA ARM64 Linux), CDP-level root-cause evidence, and a workaround that fixes cold start persistently

Environment

• Host: NVIDIA ARM64 (DGX-class), kernel 6.14.0-1013-nvidia aarch64, X11
• VS Code 1.129.1 (8a7abeba), also reproduced on 1.128.x
• openai.chatgpt versions affected here: 26.707.31428, 26.707.41301, 26.715.61943 (pre-release line). Version 26.5623.141536 ran three days of clean cold starts on the same machine.

Symptom — same as OP: after a cold start of VS Code the Codex sidebar stays on the static logo. The extension host is fully healthy the whole time (Activating Codex extension → [CodexMcpConnection] Spawning codex app-server → Initialize received id=1, no errors, client-status-changed broadcast warnings only). The webview iframe mounts, but the webview app's JS never runs.

What CDP shows (attached via --remote-debugging-port):

• On mount the webview requests ~665 bundled resource files; on a cold start this resource-loading pipeline stalls indefinitely (the renderer console simultaneously shows a listener-count explosion — VS Code's "potential listener LEAK detected" — while the app never reaches its React root render log line).
• Forcing a reload of the stuck webview with cache bypass (Page.reload ignoreCache:true) makes the app mount instantly (React root render + app routes mounted appear immediately).
• Developer: Reload Webviews also recovers it every time once VS Code is up (warm path).

What does NOT fix it — contrary to #32357: "disable-hardware-acceleration": true in argv.json. We ran 10 days with software rendering enabled; cold starts still stalled (three consecutive stuck cold starts re-verified on 2026-07-23 with the flag active). On this machine it is not a GPU-process race.

What DOES fix cold start persistently: quit VS Code and delete the Chromium caches under ~/.config/Code — Cache, Code Cache, GPUCache, DawnCache, DawnGraphiteCache, DawnWebGPUCache, Service Worker — then start VS Code again. After this wipe, current 26.5715.61943 cold-starts and renders the sidebar normally on the same machine that was stuck the same morning.

Pattern worth noting: the documented recurrences here began right after the extension auto-updated and swapped the bundled webview resources (26.5623 → 26.707, later 26.715). Together with the cache-bypass behavior above, the evidence points at stale/corrupted Chromium HTTP-cache / Service Worker state stalling the webview's resource pipeline — not at the extension backend, and (at least here) not at GPU rendering.

Happy to provide full CDP target dumps, renderer/exthost logs, or to test candidate builds.