›_ Codex Issues
Codex Issues / #32420

Codex IDE extension intermittently stalls before webview React bootstrap after extension-host recreation

Open 💬 6 comments Opened Jul 11, 2026 by bucoff
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

The Codex VS Code extension sidebar has failed more than 40 times over four days after roughly two years of reliable use on the same Linux Mint laptop. The visible result is an indefinitely shimmering logo, solid black panel, or all-gray panel.

The Codex backend on the Remote-SSH host activates, spawns codex app-server, initializes successfully, and stays alive, but failing sessions stop before the Codex webview completes its IpcRouter, Statsig, and React bootstrap. A later extension host in the same VS Code Server session sometimes succeeds with the same extension version, environment, authenticated user, and workspace. This strongly suggests an intermittent Codex webview-bootstrap timing or lifecycle defect.

The incident began shortly after Remote-SSH: Kill VS Code Server on Host was run. An extension auto-update correlated with another persistent recurrence, but neither event is claimed as the proven cause: rolling back the extension reproduced the failure.

Impact

The paid Codex IDE workflow has been unreliable or unavailable for four days. It can require five or six extension-host sessions before starting and can fail again after changing folders/repos, reloading the window, rebooting the laptop, or otherwise recreating the extension host. Codex CLI remains available but is not a replacement for the IDE workflow.

Environment

  • Client: Linux Mint 22.3, kernel 6.17.0-35-generic, AMD A8-5545M
  • VS Code: 1.128.0, commit fc3def6774c76082adf699d366f31a557ce5573f, Electron 42.5.0
  • Codex extension: openai.chatgpt@26.707.41301; rollback also tested with 26.707.31428
  • Remote host: Debian VPS via Remote-SSH, matching VS Code Server 1.128.0
  • Codex CLI: 0.144.1; codex doctor reports 17 ok / 0 warn / 0 fail
  • Other tools that remain usable: Anthropic Claude Code locally, GitHub Copilot Chat with local/remote components, and Codex CLI remotely

Repeatable working-versus-failing discriminator

Codex logs are under:

~/.vscode-server/data/logs/<session>/exthost<N>/openai.chatgpt/Codex.log

A working session continues through the webview bootstrap:

Activating Codex extension
[CodexMcpConnection] Spawning codex app-server
[IpcRouter] I am the router
[CodexMcpConnection] Initialize received id=1
... Airtable curated-plugin warning ...

[IpcRouter] I am the router
[IpcRouter] I am the router
[IpcRouter] I am the router
[statsig-refresh-diagnostics] React root render requested windowType=extension
[startup][renderer] app routes mounted after <N>ms
... normal conversation activity ...

A failing session ends at exactly 801 or 1042 bytes:

Activating Codex extension
[CodexMcpConnection] Spawning codex app-server
[IpcRouter] I am the router
[IpcClient] Received broadcast but no handler is configured method=client-status-changed
[CodexMcpConnection] Initialize received id=1
[CodexMcpConnection] cli: message="...plugin=airtable..."

<no further activity>

In the 801-byte form, the webview never announces its own IpcRouter. In the 1042-byte form, additional routers appear but Statsig and React still never mount. There is no reported exception or app-server crash.

In-session pattern

| Session | exthost1 | exthost2 | exthost3 |
|---|---|---|---|
| 04:00 UTC | fail, 801 bytes | success at 04:04:13 | — |
| 09:46 UTC | fail, 801 bytes | — | — |
| 12:23 UTC | fail, 801 bytes | fail, 1042 bytes | success at 12:28:53 |

A later extension host in the same server session sometimes succeeds. Working webviews announce their IpcRouter about one or two seconds after the plugin warning. Failing hosts never announce or announce too late for the remaining bootstrap.

Reproduction

  1. Reboot the laptop or let it sleep beyond the three-hour Remote-SSH reconnection grace period.
  2. Launch one VS Code Remote-SSH window.
  3. Open the Codex sidebar.
  4. Observe the shimmer, black panel, or gray panel.
  5. Inspect the newest remote Codex.log; it stops at 801 or 1042 bytes after initialization/plugin warning.

Changing folders/repos or reloading the window can recreate the extension host and reproduce the same failure. Occasionally a later host succeeds.

Controlled tests that did not fix it

  • Codex extension rollback from 26.707.41301 to 26.707.31428
  • Remote extension reinstall
  • VS Code Server rebuild or VPS reboot
  • Fresh VS Code profile and VS Code Insiders
  • Local folder without Remote-SSH
  • Complete Service Worker / Cache / Code Cache / GPUCache reset
  • IPv4-only VS Code CDN launch; network errors disappeared but shimmer remained
  • File-descriptor, inotify, RAM, disk, inode, and shared-memory checks; measured usage was below limits
  • MCP/plugin disablement
  • OAuth/keyring theories; CLI authentication and provider connectivity remain healthy
  • Node 24 navigator migration warning; present in working and failing sessions
  • Renderer potential listener LEAK detected; more frequent in a working session than a failing session

Questions for the extension team

  1. Why can the Codex webview stop before IpcRouter/Statsig/React bootstrap completes after extension-host recreation while a later host in the same session succeeds?
  2. What Codex-owned IDE state persists across extension binary rollback and server/session recreation?
  3. Is there a supported way to enable trace-level webview/bootstrap logging?
  4. Is there a supported reset for only Codex-owned IDE state without deleting authentication, conversation history, or unrelated extension state?
  5. Can the extension detect this bootstrap timeout and retry or surface a useful error instead of shimmering indefinitely?

A complete incident tracker and working/failing log set are available. They contain no credentials and can be provided if requested.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 9 days ago

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

  • #32385
  • #32109
  • #32041

Powered by Codex Action

bucoff · 9 days ago

Additional operational impact: when the failure occurs, the Codex extension webview never progresses beyond the shimmering/blank state, so the extension's own settings and controls are inaccessible. The operator cannot use the Codex UI to change settings, collect support information, or invoke any in-extension report/support path. VS Code's general Settings UI remains available; the blocked surface is the Codex extension webview.

ozpavel · 6 days ago

I can add a data point that removes two suspected preconditions: this reproduces fully locally (no Remote-SSH, no tunnel, no remote extension host of any kind), with freshly reset caches, and without extension-host recreation. I also captured a working/failing session pair on the same machine six minutes apart, which narrows the divergence to a single missing event.

Environment

  • VS Code: 1.128.0 (commit fc3def6774c76082adf699d366f31a557ce5573f), Electron 42.5.0
  • Codex extension: openai.chatgpt-26.707.71524-linux-x64
  • OS: Fedora Linux 44 (KDE Plasma), Wayland
  • Connection: none. Plain local window, local workspace, local extension host.

Controlled cache reset before the failing run

With VS Code fully exited, I moved aside ~/.config/Code/Service Worker, ~/.config/Code/Code Cache, and ~/.config/Code/GPUCache, so the failing session below ran with completely fresh Service Worker / code / GPU caches. It failed anyway. This matches the fresh-profile reproduction reported in #32109 and rules out stale Service Worker state as a necessary condition.

Failing session (21:48 local time, fresh caches, single extension host)

Codex.log ends here and never resumes:

21:48:17.523 [info] Activating Codex extension
21:48:17.523 [info] [CodexMcpConnection] Spawning codex app-server
21:48:17.523 [info] [IpcRouter] I am the router
21:48:17.523 [warning] [IpcClient] Received broadcast but no handler is configured method=client-status-changed
21:48:17.523 [info] [IpcRouter] I am the router
21:48:17.523 [info] [IpcRouter] I am the router
21:48:17.524 [warning] [IpcClient] Received broadcast but no handler is configured method=client-status-changed
21:48:17.559 [info] [CodexMcpConnection] Initialize received id=1

Renderer log for the same window, about 1.4 s after activation:

21:48:18.914 [error] potential listener LEAK detected, popular: Error
    at jle.doReadFileStream -> readFileStream -> loadResource (webviewElement)
21:48:18.921 [error] potential listener LEAK detected, dominated: Error
    (same stack)

The sidebar showed the static logo indefinitely. Two minutes in, the webview renderer process was sustaining ~40% CPU and the GPU process ~42% while displaying a static image. The extension host was NOT recreated in this run (single "Activating Codex extension", single exthost pid), so host recreation is not required to trigger it either.

Working session (21:54, same machine, same binaries, nothing changed in between)

Identical log prefix through Initialize received id=1, and the renderer emitted the SAME two listener-LEAK errors with the same stack. Then, about 4 s after activation:

21:54:54.863 [info] [statsig-refresh-diagnostics] React root render requested windowType=extension
21:54:57.364 [info] [startup][renderer] app routes mounted after 6262ms
21:54:57.372 [info] [statsig-refresh-diagnostics] ready provider mounted instanceId=1 windowType=extension

Observations

  1. The listener-LEAK warnings are NOT the discriminator: they appear identically in both the failing and the working session. They just mark the webview asset-load burst happening.
  2. The working and failing sessions are byte-for-byte identical up to Initialize received id=1. The only divergence is whether React root render requested appears ~4 s later. In failing sessions the webview's JS bundle apparently never finishes loading/executing, so React never mounts, and there is no error surfaced anywhere - the app-server stays alive and idle, waiting forever.
  3. Given the webviewElement.loadResource stack and the local-only reproduction, this is consistent with the VS Code core streamed webview-resource path (microsoft/vscode#319468, introduced by microsoft/vscode#311844 in 1.118) intermittently failing to deliver part of the extension's large JS/CSS asset set. When a required chunk is lost, the module graph never completes and the webview hangs silently.

Two suggestions regardless of where the root cause lands:

  • The extension could detect "Initialize received but no React mount within N seconds" and retry the webview or surface an error, instead of an indefinite logo.
  • Reducing the number of separate webview assets (~hundreds of JS/CSS files per load, per the fan-out measured in #32385) would shrink the window in which the VS Code resource-streaming race can strike.

codex-webview-hang-logs-minimal-20260714.zip

bucoff · 2 days ago

Follow-up (2026-07-18): same extension version bootstrapped and failed on consecutive days — rules out update/reinstall as a fix.

Since the original report, the extension auto-updated to openai.chatgpt@26.707.71524 (2026-07-15). On that unchanged build, on the same machine / user / workspace:

  • Worked: session 20260716T172905/exthost2 bootstrapped fully ([startup][renderer] app routes mounted after 13476ms) and ran continuously from 2026-07-16 17:31 to past

2026-07-17 08:12 UTC.

  • Failed the next morning: two fresh sessions on the same 71524 build — 20260718T034130/exthost1 and 20260718T040926/exthost1, both exactly 1037 bytes — stopped at the

pre-bootstrap point (no webview IpcRouter, no statsig, no React mount).

Same version, working one day and failing the next, confirms this is an intermittent webview-bootstrap race triggered by extension-host recreation
(reboot/sleep/reload/reconnect), not any extension version. Updating or reinstalling cannot resolve it. Disabling laptop GPU acceleration also had no effect (the working streak
above was the race landing favorably). Requesting a root-cause fix for the webview bootstrap — there is no user-side configuration that resolves it.

Mahkhmood9 · 1 day ago

If anyone can trace it

systemd/ulimit/Electron/Vscode

per what whats on here it would be great

Im trying to personally why https://github.com/openai/codex/issues/32041 is happening

i suspect something in VScode has changed or Electron
before blaming codex-ide

bucoff · 1 day ago

This workaround appears to resolve the issue:

  • VS Code renderer initially inherited a soft open-file limit of 1024.
  • Launching VS Code with ulimit -n 65535 allowed the Codex webview to bootstrap normally.
  • I made this persistent through a Linux Mint desktop launcher wrapper.
  • The renderer now reports Max open files 65535.

I’m going to verify this across a reboot and several extension-host reloads before closing the issue. This may be an environmental workaround rather than the underlying root-cause fix.