›_ Codex Issues
Codex Issues / #33968

Codex VS Code sidebar intermittently hangs on the logo or renders blank on Linux/Wayland

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

What version of the IDE extension are you using?

openai.chatgpt 26.715.31925 (linux-x64, stable channel)

Bundled Codex binary: codex-cli 0.145.0-alpha.18

Which IDE are you using?

Visual Studio Code 1.129.1

  • Commit: 8a7abeba6e03ea3af87bfbce9a1b7e48fed567b8
  • Date: 2026-07-17T15:35:09Z
  • Linux x86_64
  • Wayland session

What issue are you seeing?

The Codex sidebar intermittently remains on the logo/loading screen forever. Restarting VS Code or disabling and re-enabling the Codex extension often does not fix it. The Codex CLI works and both the standalone and extension-bundled Codex binaries report that they are logged in through ChatGPT.

When the sidebar is stuck, the Codex log stops immediately after the app server initializes:

[info] Activating Codex extension
[info] [CodexMcpConnection] Spawning codex app-server
[info] [IpcRouter] I am the router
[info] [CodexMcpConnection] Initialize received id=1

It never reaches the frontend startup messages seen during a successful launch:

[statsig-refresh-diagnostics] React root render requested windowType=extension
[startup][renderer] app routes mounted
[statsig-refresh-diagnostics] ready provider mounted instanceId=1 windowType=extension

During one recovery attempt using Developer: Reload Webviews, VS Code's main-process log also recorded:

Blocked vscode-webview request vscode-webview://<redacted>/index.html?...&extensionId=openai.chatgpt&...&purpose=webviewView

The issue was initially observed with VS Code hardware acceleration disabled. Enabling it coincided with one successful launch, but a later clean launch with hardware acceleration enabled failed in exactly the original way: the log again stopped after Initialize received id=1, with no React-root or route-mount messages. Another launch briefly showed a plain gray Codex panel. Repeated full restarts eventually made the panel work again.

Therefore, changing hardware acceleration is not a reliable workaround and does not appear to be the root cause. The consistent distinction is that the WebView frontend never connects to the extension's IPC router on failed launches. A successful launch creates the additional frontend IPC connections and mounts the React application.

Further isolation initially appeared to point to VS Code Chromium/WebView user-data state, but resetting that state was also not a stable fix:

  • Codex mounted successfully in multiple temporary VS Code user-data directories, including both native Wayland and X11/XWayland launches.
  • It also mounted successfully in a temporary user-data directory containing a complete copy of the original VS Code User/ directory, which preserved the original settings, global extension state, and workspace state while excluding the old Chromium/WebView data.
  • The real VS Code user-data root was then backed up and rebuilt, restoring only the original User/ directory. The first cold launch mounted successfully and logged React root render requested, app routes mounted, and ready provider mounted.
  • On later restarts, the intermittent hang returned. Sometimes it works and sometimes it does not, without any configuration change.

This means that rebuilding VS Code WebView/Chromium state may coincide with a successful launch, but it is not a reliable workaround. The failure still behaves like a timing-sensitive or random WebView frontend/IPC bootstrap problem.

Steps to reproduce

  1. On Linux/Wayland, install the stable Codex VS Code extension.
  2. Fully exit and start VS Code, then open the Codex sidebar.
  3. Intermittently, the sidebar stays on the Codex logo/loading screen forever or becomes a plain gray panel.
  4. Fully restart VS Code several times. Some launches eventually succeed without any configuration change.
  5. Compare the Codex logs: failed launches stop after app-server initialization, while successful launches contain the React-root and route-mount messages shown above.

The problem has occurred with hardware acceleration both disabled and enabled. Developer: Reload Webviews, restarting VS Code, and disabling/re-enabling the extension are not reliable recovery methods.

Rebuilding the VS Code user-data root while preserving User/ is also not a reliable recovery method: it fixed the first launch but the same issue returned on later restarts.

Expected behavior

The Codex sidebar should start reliably. If the WebView frontend cannot connect to IPC or its request is blocked, the sidebar should show an actionable error instead of loading forever or displaying a blank panel.

Additional information

  • No authentication failure was present; both Codex binaries reported Logged in using ChatGPT.
  • One failed launch logged a remote plugin-catalog warm-up network error about 37 seconds after initialization, but the frontend bootstrap had already failed to occur. Other sessions also contained later network failures, including sessions where the frontend mounted, so this does not appear to explain the missing frontend IPC connection.
  • The Blocked vscode-webview request message occurred during one manual WebView-reload attempt. It did not appear in the latest failed clean launch, so it may be a recovery-path symptom rather than the primary cause.
  • Hardware acceleration was enabled for the latest failed launch, confirming that the earlier successful launch after changing this option was only a correlation, not a stable fix.
  • Clean temporary user-data tests succeeded on both Wayland and X11/XWayland, and a rebuilt real user-data root also succeeded once before the problem returned. Therefore neither the display backend nor persistent user configuration alone explains the failure.
  • There is currently no stable local workaround. Repeated full restarts sometimes recover the panel, but identical launches can either succeed or hang.
  • Similar symptoms have been reported in #9615 and #15975, but those reports do not include this Linux/Wayland runtime configuration or the Blocked vscode-webview request evidence.
  • Full logs and private filesystem paths are intentionally omitted, but additional redacted diagnostics can be supplied if needed.

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 2 days ago

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

  • #33032

Powered by Codex Action

Persenz1 · 2 days ago

Thanks for flagging #33032. The visible symptom and the point where the Codex log stops are similar, but my case does not currently appear to be explained solely by the stale service-worker cache described there.
In #33032, the failure is tied to an in-place extension update and stale cached asset URLs pointing to a deleted previous extension directory. In my case, I rebuilt the entire VS Code user-data root while preserving only User/. The first cold launch succeeded, but the same intermittent failure returned on subsequent restarts without another extension update or configuration change. Identical launches can either succeed or fail.
I also observed one Blocked vscode-webview request, whereas I have not yet confirmed the decisive net::ERR_FAILED asset-chunk failures reported in #33032.
I will keep this issue open unless Webview Developer Tools confirms that failed launches are resolving assets against an obsolete extension directory. At present, #33032 may be a related failure mode, but it does not fully account for the intermittent recurrence after rebuilding the WebView/Chromium state.

________________________________
发件人: github-actions[bot] @.*>
已发送: 2026 年 7 月 18 日 星期六 下午 03:20
收件人: openai/codex @.*>
抄送: Percy Liu @.>; Author @.>
主题: Re: [openai/codex] Codex VS Code sidebar intermittently hangs on the logo or renders blank on Linux/Wayland (Issue #33968)

[https://avatars.githubusercontent.com/in/15368?s=20&v=4]github-actions[bot] left a comment (openai/codex#33968)<https://github.com/openai/codex/issues/33968#issuecomment-5010385398>

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

  • #33032<https://github.com/openai/codex/issues/33032>

Powered by Codex Action<https://github.com/openai/codex-action>

―
Reply to this email directly, view it on GitHub<https://github.com/openai/codex/issues/33968?email_source=notifications&email_token=B3HLS7QR7DM2UUHL356SKDD5FMQMBA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBRGAZTQNJTHE4KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5010385398>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/B3HLS7SJNNTFWYV6RQB4TG35FMQMBAVCNFSNUABFKJSXA33TNF2G64TZHM4TMNJUGE2TMNBZHNEXG43VMU5TIOJRG4ZDKNZWG4YKC5QC>.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/B3HLS7UDWBJ4KONAC7LDWIT5FMQMBA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBRGAZTQNJTHE4KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android<https://github.com/notifications/mobile/android/B3HLS7UWEUNVNWMP2KVPI435FMQMBA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBRGAZTQNJTHE4KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today!
You are receiving this because you authored the thread.Message ID: @.***>

ChrisLauinger77 · 2 days ago

Independent reproduction on Debian GNU/Linux forky/sid, GNOME Wayland (x86_64).

Environment:

  • VS Code 1.129.1, commit 8a7abeba6e03ea3af87bfbce9a1b7e48fed567b8
  • Codex extension openai.chatgpt 26.715.31925
  • Session: GNOME / Wayland

Observed behavior matches this report exactly. The sidebar shows only the Codex logo or a plain gray unloaded panel. Restarting the extension host, reloading the VS Code window, and fully restarting VS Code are unreliable. Opening or switching projects can reproduce the failure.

The Codex app-server consistently starts and initializes:

Activating Codex extension
[CodexMcpConnection] Spawning codex app-server
[CodexMcpConnection] Initialize received id=1

On a successful launch, the log additionally contains:

[statsig-refresh-diagnostics] React root render requested windowType=extension
[startup][renderer] app routes mounted
[statsig-refresh-diagnostics] ready provider mounted instanceId=1 windowType=extension

On failed launches those frontend messages are absent, even though app-server initialization succeeds. This supports the WebView/frontend IPC bootstrap diagnosis.

Additional isolation performed:

  • A temporary clean VS Code user-data directory loaded the Codex UI successfully.
  • Removing only the openai.chatgpt entry from VS Code state.vscdb temporarily recovered the UI, but the failure returned after changing projects.
  • Removing the Codex WebView origin entries did not provide a durable fix.
  • With VS Code completely closed, all normal-profile Chromium/WebView caches (Cache, Code Cache, GPUCache, Service Worker, Session Storage, and WebStorage) were moved aside so VS Code rebuilt them. The failure still returned.
  • Opening projects in separate new windows did not avoid the failure; multiple windows could both show gray unloaded Codex panels.

No authentication failure was observed, and actual Codex conversations remained available. The extension update cadence makes this especially disruptive because ordinary restarts and cache/state resets do not reliably recover the frontend.

A built-in timeout with an actionable WebView restart/recovery path would be much better than leaving the panel indefinitely on the logo.

axolul · 2 days ago

Additional root-cause evidence from an affected Ubuntu 24.04.4 VM, this time under X11/xrdp, indicates this is not Wayland-specific and points to VS Code's Linux WebView resource-loading FD exhaustion rather than Codex authentication or app-server startup.

Tested versions:

  • VS Code 1.129.1, commit 8a7abeba6e03ea3af87bfbce9a1b7e48fed567b8
  • Electron 42.6.0
  • openai.chatgpt 26.715.31925

What I observed:

  • The Codex app-server consistently spawned and returned Initialize received id=1.
  • Failed launches never logged React root render requested, app routes mounted, or ready provider mounted.
  • A renderer Crashpad minidump from a cold failure records SIGBUS / BUS_ADRERR, with the fault in glibc __memcpy_avx512_unaligned_erms.
  • Developer: Reload Window reproduced the failure. The kernel then logged an invalid-opcode trap in the WebView compositor adjacent to V8 BackingStore handling. One second earlier, the renderer log reported a potential listener leak with a stack ending in VS Code's WebviewElement.loadResource path.
  • The installed Codex WebView bundle is about 148 MiB and contains 4,959 asset files.
  • The VS Code renderer and zygote processes had RLIMIT_NOFILE soft limit 1024 (hard limit 1,048,576), while the main process, extension host, and Codex app-server had 1,048,576. This also explains why simply launching VS Code from a shell with a larger ulimit -n is not sufficient here.
  • Only one Codex app-server was alive during reproduction. Disk space, RAM, swap, /dev/shm, and filesystem health were normal, with no OOM or I/O errors.

This matches the diagnosis in microsoft/vscode#326092 and its follow-up fix microsoft/vscode#326272: Codex can generate roughly 625 concurrent WebView resource requests; Mojo uses shared-memory file descriptors for larger bodies; Linux's sandboxed renderer is limited to 1024 FDs. VS Code commit 17d3b86b9361cba49d8d0238787d9aa590e657ca caps active WebView resource bodies at 32 and is targeted at VS Code 1.130.0.

As of this check, the official Linux x64 Insiders build is commit 5e212606d57c0a17f73bc8b7ae0cc9e14bcfd345, which GitHub's compare API reports as 16 commits behind that fix, so it is not yet a valid verification build. I will retest once the official build advances to the fix or a descendant.

I retained the raw minidumps locally but have not uploaded them because minidumps can contain process memory. I can provide additional sanitized crash metadata if useful.

seldontrantor · 20 hours ago

VS Code Version: 1.129.1

OS Version: Linux Ubuntu 22.04

VS Code doesn't crash anymore but the codex (v 26.715.31925) is not loading and the codex panel is stuck in Open AI logo or a gray page.

<img width="417" height="1026" alt="Image" src="https://github.com/user-attachments/assets/4d2bd287-5778-49c0-ba7e-5a90286dfc00" />

nckirik · 18 hours ago

you can try the workaround i posted at https://github.com/openai/codex/issues/34308

arpu · 8 hours ago

same with flatpak installed code #34308 not working for the flatpak installed code