White screen of death - Codex starts and then crashes immediately

Console logs show:

ERR navigator is now a global in nodejs ... PendingMigrationError
    at get (.../extensionHostProcess.js:805:7210)
    at /home/node/.vscode-server/extensions/openai.chatgpt-26.506.20924-linux-x64/out/extension.js:1:11801
    ...
    at Object.<anonymous> (/home/node/.vscode-server/extensions/openai.chatgpt-26.506.20924-linux-x64/out/extension.js:437:39248)

remoteAuthority=dev-container+...
VS Code server path: /vscode/vscode-server/bin/linux-x64/f6cfa2ea...
Codex/OpenAI extension: openai.chatgpt-26.506.20924-linux-x64
Remote Containers extension: ms-vscode-remote.remote-containers-0.459.0
Remote SSH extension: ms-vscode-remote.remote-ssh-0.123.0

Output logs shows nothing useful:

2026-05-26 10:12:07.972 [info] Activating Codex extension
2026-05-26 10:12:07.972 [info] [CodexMcpConnection] Spawning codex app-server
2026-05-26 10:12:07.972 [error] [CodexMcpConnection] cli: message="codex_app_server: Codex could not find bubblewrap on PATH. Install bubblewrap with your OS package manager. See the sandbox prerequisites: https://developers.openai.com/codex/concepts/sandboxing#prerequisites. Codex will use the bundled bubblewrap in the meantime."
2026-05-26 10:12:07.975 [info] [CodexMcpConnection] Initialize received id=1
2026-05-26 10:12:08.475 [warning] [CodexMcpConnection] cli: message="codex_core_plugins::startup_remote_sync: startup remote plugin sync failed; will retry on next app-server start error=remote marketplace `oai-maintained-plugins` is not available locally"
2026-05-26 10:12:08.578 [warning] [IpcClient] Received broadcast but no handler is configured method=client-status-changed
2026-05-26 10:14:07.186 [warning] [IpcClient] Received broadcast but no handler is configured method=client-status-changed
2026-05-26 10:14:08.265 [info] [IpcRouter] I am the router
2026-05-26 10:14:08.265 [info] [IpcRouter] I am the router

On latest version (26.519.32039), still:

PendingMigrationError: navigator is now a global in nodejs
...
/home/node/.vscode-server/extensions/openai.chatgpt-26.519.32039-linux-x64/out/extension.js

Update: PendingMigrationError: navigator is now a global in nodejs appears even when the extension starts up normally, so it's probably a red herring.

Also,

Uncaught (in promise) NetworkError: Failed to execute 'put' on 'Cache': Cache.put() encountered a network error
    at service-worker.js...

and,

potential listener LEAK detected
...
loadResource @ webviewElement.ts:785

ChatGPT suggests: "it suggests the white screen may involve webview resource loading/caching repeatedly failing, not just the extension-host activation error."

I also reproduced the error on my laptop without remote or devcontainer involved.

However, starting a fresh vscode profile got the extension working.

code --user-data-dir /tmp/vscode-codex-test-user \
     --extensions-dir /tmp/vscode-codex-test-exts

then I installed Codex and it worked.

And, weirdly, after returning to my normal profile, Codex also started working again, including inside the devcontainer. I did not intentionally change extensions or settings.

Maybe failure involves stale extension host state, stale webview/service-worker cache, a half-completed extension update, or Codex app-server/IPC state (not necessarily a configuration issue)?

Update: The extension continued to work for a day but then stopped working again with the same issue, and restarting in a fresh profile did not get it working in the original workspace this time.

The fresh-profile result is interesting because it suggests at least two separate states may be involved:

• extension-host activation can fail with PendingMigrationError: navigator is now a global in nodejs;
• the webview/service-worker cache path can then leave the UI blank or unstable;
• clearing state by using a fresh profile temporarily helped, but the original workspace later regressed again.

For triage, I would try to separate extension activation from webview rendering:

1. capture whether the PendingMigrationError appears before any Codex webview is opened;
2. clear only VS Code webview/service-worker storage, without reinstalling the extension, and see whether the white screen changes;
3. test the same workspace with the extension disabled/enabled after deleting only the extension global storage;
4. compare local VS Code vs Remote SSH vs Dev Container with the same extension build.

If maintainers can identify which cached state makes a good profile become bad again, this may be reproducible without the full devcontainer setup.

I'm getting this error more reliably when connecting from macOS VS Code 1.121.1 to a remote SSH machine with linux.
Downgrading VS Code to 1.115.0 helped.

My setup:
IDE version: 26.602.30954
VS Code version: 1.122.1 (via remote SSH tunnel to server)
OS: client: Darwin 25.5.0 arm64 arm; remote: Linux 6.1.0-35-arm64 aarch64 unknown

Duplicates of this issue: #25716, #26509, #24601

Seems like a lot of people experience this 😅

I’m also seeing a similar Codex IDE Extension issue on Linux + VS Code.

Observed behavior:

• Yesterday, opening the Codex panel got stuck on a blank/loading webview.
• After waiting, VS Code became unresponsive / crashed.
• Today the same panel can load again, so the issue appears intermittent or related to a transient webview/auth/service state.

Impact:

• High severity while it happens, because Codex makes the whole editor unusable and I have to disable/restart VS Code to continue working.

Environment details I can provide later if needed:

• OS: Linux
• IDE: VS Code
• Component: Codex IDE Extension
• Account plan: ChatGPT Plus

I do not have complete logs attached yet, but the visible symptom was a blank Codex tab with only the loading spinner before the editor crash/freezing.

This issue seems to come and go periodically for me. For instance, I just noticed that restarting vscode with wayland made the issue appear, and restarting it with x11 made it work again. (I'm just documenting this because I have no idea what's causing it or how to reliably reproduce it yet.)

code --ozone-platform=x11

Additional data point from a local Fedora VS Code profile. This looks related to the same blank/white-screen class, but I found one concrete persisted VS Code state row that may help narrow it down.

Environment:

• IDE: VS Code 1.125.1, commit fcf604774b9f2674b473065736ee75077e256353, x64
• Extension: openai.chatgpt@26.616.32156
• Platform: Linux 7.0.12-201.fc44.x86_64 x86_64 unknown
• Local VS Code window, not Remote SSH / Dev Container for this repro

Observed behavior:

• Codex auto-updated while an existing VS Code process was still running.
• Without fully exiting that first VS Code process, I launched another VS Code process/window.
• After that, the right-side Chat/Copilot area could still open and Copilot worked.
• The Codex tab/container was visible next to Chat, but switching to Codex did not render the Codex work area/content.
• A clean temporary VS Code profile could load Codex normally, which pointed back to persisted profile/workspace state rather than the account/session itself.
• I eventually had to fully reset the VS Code profile to recover. Crashpad dumps were generated around the failure window, but I am not attaching them publicly because they may contain local state.

The most interesting evidence was in VS Code workspaceStorage/<workspace-id>/state.vscdb. The workspace state said the Codex container was visible, but the child Codex webview view was hidden:

workbench.auxiliarybar.viewContainersWorkspaceState = [{"id":"workbench.panel.chat","visible":true},{"id":"workbench.view.extension.codexSecondaryViewContainer","visible":true}]
workbench.view.extension.codexSecondaryViewContainer.numberOfVisibleViews = 1
workbench.view.extension.codexSecondaryViewContainer.state = {"chatgpt.sidebarSecondaryView":{"collapsed":false,"isHidden":true,"size":988}}
memento/webviewView.chatgpt.sidebarSecondaryView = {}

The extension host log showed Codex activation and app-server initialization, so this did not look like a simple failure to activate the extension:

ExtensionService#_doActivateExtension openai.chatgpt, activationEvent: 'onView:chatgpt.sidebarSecondaryView'
[info] Activating Codex extension
[info] [CodexMcpConnection] Spawning codex app-server
[info] [CodexMcpConnection] Initialize received id=1

My current hypothesis is that an extension update / reload / multi-window sequence can leave VS Code persisted UI state in an inconsistent condition: the outer Codex view container remains visible, while chatgpt.sidebarSecondaryView is persisted as hidden. Once this state exists, the Codex panel can appear blank/non-rendering even though the extension activates.

This may be separate from, or layered on top of, the webview/service-worker/cache issues discussed above. A useful mitigation might be for the extension to validate/reset its view-container state on activation, especially when workbench.view.extension.codexSecondaryViewContainer is visible but chatgpt.sidebarSecondaryView is hidden.

Additional confirmed data point from Fedora 44 / local VS Code profile. I am adding this here instead of opening a new issue because it appears to be the same blank/white-screen webview failure class.

Environment:

• Fedora 44, Linux x64
• VS Code 1.128.0
• VS Code commit fc3def6774c76082adf699d366f31a557ce5573f
• Codex extension openai.chatgpt@26.707.31428
• Local VS Code profile, not Remote SSH / Dev Container

Symptom:

The Codex container/view was visible and the extension activated, but the Codex webview did not finish rendering. The Codex log stopped after app-server initialization:

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

It did not reach:

Features enabled
[startup][renderer] app routes mounted

Evidence:

The normal VS Code profile had stale Codex webview resources in:

~/.config/Code/WebStorage/*/CacheStorage

The cache contained resources from many removed Codex extension versions, including:

openai.chatgpt-26.616.51431-linux-x64
openai.chatgpt-26.623.141536-linux-x64
openai.chatgpt-26.623.41415-linux-x64
openai.chatgpt-26.707.31428-linux-x64

Only openai.chatgpt-26.707.31428-linux-x64 was installed at the time.

Validation:

I moved only these VS Code cache directories out of the profile:

~/.config/Code/WebStorage
~/.config/Code/Service Worker

I did not remove ~/.codex, the extension install, credentials, workspace storage, or global extension state.

After restarting VS Code, Codex rendered again. The new log reached:

Features enabled ...
[startup][renderer] app routes mounted after 5635ms

Impact:

This has happened more than once on my Linux environments. When it happens, the Codex IDE extension becomes unusable even though the extension appears installed and activated. The workaround requires knowing which VS Code webview/cache state to clear, which is not obvious to users.

This looks like Codex may need stronger webview asset cache busting / invalidation after extension updates, or at least a startup diagnostic/recovery path when the app-server initializes but the webview renderer never mounts.

Correction and stronger native-crash evidence from my Fedora/Ubuntu investigation.

My previous comment attributed recovery too strongly to stale Webview cache. Cache cleanup did restore one launch, but subsequent controlled reproductions show that stale cache contents are not the current root cause.

Environment

• Fedora 44 host and an independent Ubuntu VM, both Linux x64
• VS Code 1.128.0, commit fc3def6774c76082adf699d366f31a557ce5573f
• Electron 42.5.0, Chromium 148.0.7778.271
• Codex extension openai.chatgpt@26.707.31428
• Local VS Code windows, not Remote SSH or Dev Containers

Confirmed native signature

I now have seven relevant Crashpad dumps: three from Fedora and four from Ubuntu. All seven have the same signature:

exception code     7 (SIGBUS)
exception flags    2 (BUS_ADRERR)
copy length        0x40033 (262195 bytes)
return address     /usr/share/code/code+0x9fada74

The source address is page-aligned. The faulting libc AVX load reads at source + 0x40013, in the final page implied by the advertised span. The direct VS Code/Electron caller invokes memcpy and returns at code+0x9fada74 in every dump.

Static mapping of the VS Code/Chromium build places this path at:

Blink CloneableMessage::Read
  -> mojo_base::BigBufferView::data()
  -> blink::SerializedScriptValue::Create()
  -> memcpy(size = 0x40033)
  -> SIGBUS / BUS_ADRERR

The crashing process is a renderer for a vscode-webview:// origin loading the installed Codex Webview assets.

The newest dump was created at 2026-07-10 20:01:51 +08:00 after a complete VS Code Window State reset:

dump:   host-da011cec-f0ec-4992-a397-1670526877e5.dmp
sha256: edd7281c79b421f331fa8775bee598f87a9cc846485cae5280c2e615f32de479
fault:  0x7f17a56f5013
source: 0x7f17a56b5000

I am not uploading raw dumps publicly because they can contain process memory, but I can provide them through a private maintainer channel.

Failure boundary

During failed launches, the extension host and bundled Codex app-server are alive and initialization succeeds:

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

The Webview never reaches:

React root render requested
[startup][renderer] app routes mounted
ready provider mounted

Inspection of the installed Webview bundle shows that React rendering waits for the Webview RPC remoteMain.services object. That bootstrap uses VS Code webview.postMessage() / onDidReceiveMessage() and has no timeout or retry. If the renderer dies, the visible panel remains blank indefinitely even though the extension and app-server initialized successfully.

Controls and exclusions

• The Ubuntu VM produced the same SIGBUS after the Webview/Electron caches had been deleted and recreated. Cache contents are therefore not a sufficient root-cause explanation.
• On Fedora I removed all 12 workspaceStorage directories, cleared window restoration references, and removed 53 global Workbench/Webview layout keys while VS Code was closed. The very next ordinary launch produced the seventh matching SIGBUS. Window State is not the native-crash root cause.
• Restarting the terminal Codex CLI, bundled app-server, or Extension Host is not sufficient. The terminal CLI and extension-bundled app-server are separate processes.
• Clearing Webview/Chromium runtime caches can restore the next launch, but it is an operational workaround that changes runtime state/timing rather than a permanent fix.

One additional launch-path observation: repeated external launches with

code --new-window <project-path>

currently avoid the failure on this host, while the normal desktop launcher and VS Code's internal vscode.openFolder(..., { forceNewWindow: true }) path can still fail. This suggests a window/Webview creation timing or lifecycle difference; forceNewWindow through the extension API is not operationally equivalent to the external CLI path for this bug.

Maintainer actions that would help

1. Identify which Codex/Webview structured-clone message consistently has length 0x40033.
2. Instrument the Mojo BigBuffer shared-memory mapping/backing size and lifetime for that message on Linux.
3. Add a timeout/renderer-exit recovery path around Webview RPC bootstrap so a dead renderer is recreated instead of leaving a permanently blank panel.

The exact sender and shared-memory lifetime error require product symbols/instrumentation, but the cross-machine native signature and failure boundary are now deterministic enough for maintainer triage.