Codex IDE extension stuck loading over VS Code Remote-SSH while CLI works

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

• #26509
• #25716
• #26606

Powered by Codex Action

This may be related to the existing PendingMigrationError issues, but it does not appear to be an exact duplicate. After setting "extensions.supportNodeGlobalNavigator": true both locally and remotely, the remote extension host starts with --supportGlobalNavigator and the latest remote Codex logs no longer show PendingMigrationError. However, the Codex panel is still stuck loading while Codex CLI works and codex app-server is running. The remaining logs show "IpcClient Received broadcast but no handler is configured" and the ngs-analysis defaultPrompt warning.

Also happens on Ubuntu. Until a week ago it sometimes worked when you restarted vscode a few times, now it never works anymore, in remote workspace the panel just does not load. Mentioning this because a windows-os label is assigned.

Same problem at Bazzite DX. I have same problem as @caramboleyo described. I thought I did something wrong, when I am installed the extension. But, the codex cli works fine.

I have the same problem too, when I use 'remote explorer' to ssh to the the virtual computer. The codex extension does not work on it. It just show the blank. But the codex-cli still works.

same on mac and ubuntu, sometimes work, sometimes it wont load after multiple restart. the unreliability is driving me away from open ai.

i am back on my notebook where an older vscode version is running (before the agents button in the top panel) and here it works fine yet.

Version: 1.109.5
Commit: 072586267e68ece9a47aa43f8c108e0dcbf44622
Date: 2026-02-19T19:43:32.382Z
Electron: 39.3.0
ElectronBuildId: 13313481
Chromium: 142.0.7444.265
Node.js: 22.21.1
V8: 14.2.231.22-electron.0
OS: Linux x64 6.17.0-35-generic

Does anyone have a fix yet for this. I tried a few things..but nothing is working

Step 1: Downgrade the Extension
Open VS Code.

Click on the Extensions icon in the left sidebar (the icon with four squares) or press Cmd + Shift + X.

Search for your Codex extension (usually listed as OpenAI ChatGPT or Codex).

Select the extension to open its details page.

Click the small drop-down arrow right next to the "Uninstall" button.

Select Install Another Version...

A menu will drop down from the top of the screen showing a list of version numbers. Select the version immediately preceding the one currently installed (for example, if you are on 26.527.60818, choose 26.527.31454).

Wait for it to install, and then click Reload Required when prompted.

Step 2: Disable Auto-Updates (Crucial)
If you do not disable auto-updates, VS Code will silently update Codex back to the broken version the next time you restart your editor.

On the Codex extension's details page, click the Gear icon ⚙️ next to the Uninstall button.

Uncheck Auto Update (or select "Ignore Updates" if that is the option presented).

Step 3 (Backup): The Settings Shim
If downgrading doesn't immediately fix the issue (especially if you are using VS Code Remote-SSH to connect to another machine), you can try forcing VS Code to allow the global navigator temporarily.

Open your VS Code Settings (Cmd + ,).

Search for supportNodeGlobalNavigator.

If it appears, check the box to set it to true. (If you use Remote-SSH, make sure you apply this to the Remote settings tab as well).

Fully restart VS Code.

Once the sidebar loads again, your chat history and local server should start responding normally.

Just did this and it worked! I then went back and upgraded the version to the newest and it still works!

I've found a working workaround for Windows host and Linux target device, I verified this solution works for both Raspberry Pi 5 and NVIDIA Jetson Orin Nano targets.

Here's how I solved the issue of Codex sidebar crashing VSC for SSH targets:

Step One:
On target device, either ssh via terminal/powershell or through the terminal of the target device itself, perform the following:
< Install Codex CLI >
</> bash

curl -fsSL https://chatgpt.com/codex/install.sh | sh
codex --version
which codex

%% to ensure Codex CLI runs on target device...

Step Two:
< Login to Codex on target device(s) >
</> bash
codex
%% then following instructions to login to your Codex account

Step Three: (Important?)
I found that one of the ways to avoid VSC crashing from Codex sidebar, is to ensure SSH to your target device does not prompt a password
There are several ways to workaround removing password for ssh, but my approach tested using Windows host is:
< From host device, create config file that makes SSH into your target not requiring any password / passphrase >
</> PowerShell

ssh-keygen -t edXXXXX -f "$env:USERPROFILE\.ssh\id_edXXXXX_codex_yourDevice" -C "codex-yourDevice"
%% XXXXX is any numeric value you decide, # yourDevice is your target device 
%% When it asks for passphrase, just enter twice without inputting any passphrase
type "$env:USERPROFILE\.ssh\id_edXXXXX_codex_yourDevice.pub" | ssh yourUSERNAME@IP-ADDRESS "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"
%% This step will ask for your password one last time, after which you will never be prompted for password
%% ssh yourUSERNAME@IP-ADDRESS is the ssh command for your target device, please modify

Step Four:
Add the SSH alias into your Windows config to make it passwordless and no passphrase:
</> PowerShell
notepad "$env:USERPROFILE\.ssh\config"

%% Add the following:

Host yourDevice-codex
    HostName IP-ADDRESS #of target
    User username #username of target
    IdentityFile C:/Users/YourWindowsUser/.ssh/id_edXXXXX_codex_yourDevice
    IdentitiesOnly yes
    PreferredAuthentications publickey

%% Make sure to modify the above as per your host and target users

Step Five:
Verify that your SSH is now passwordless from your host:
</> PowerShell

ssh yourDevice-codex

or ssh yourUSERNAME@IP-ADDRESS

%% These should be able to ssh into your target device without prompting either a password or passphrase (if passphrase is asked, it might be because you entered a passphrase at Step 3, redo Step 3 if you did)
%% With a passphrase, you won't be able to enter VSC without password, so make sure this is not the case.

If you are able to verify SSH is passwordless from powershell, now try to Connect to Host from VSC, this time it should not ask for a password.

Step Six:
Having installed Codex CLI and making your SSH password-less on VSC. Now verify if Codex sidebar loads properly.

The steps above worked for me on 2 separate Linux target device.

Same problem. On laptop with Ubuntu 26.04 codex plugin works in vs code, but on rpi over ssh is not.

Same issue on both MacOS and Ubuntu 26.04. Found that VS Code loads the Codex extension but extension appears blank when connecting to another system via SSH. Codex CLI via terminal works fine. Interestingly, when opening only one VS Code window with a local directory, the extension works fine. As soon as I open an additional VSC window to the SSH system, the local window extension also freezes in addition to the remote VSC window extension appearing blank.

Have attempted version rollbacks and disable/reenable and uninstall/reinstall to no avail.

I had similar issue but with running codex extension locally. Command "Codex: New Codex Agent" opened codex and cli worked, but sidebar extension never loaded. I have talked about this with chatgpt-5.5 and found solution.

Root error

The Developer Tools console showed a frontend module-loading failure (amongs other errors which were irrelevant):

Uncaught SyntaxError: The requested module
'./open-project-setup-dialog-WAywOZ1R.js'
does not provide an export named 'H'

Important diagnostic

The extension worked correctly in a completely temporary VS Code profile (indicated that the extension package and app-server could work, and that the problem was related to persisted VS Code webview/browser state in my normal profile):

code \
  --user-data-dir /tmp/vscode-codex-profile \
  --extensions-dir /tmp/vscode-codex-extensions

Workaround

Close all vscode windows prior and delete cache files (chatgpt suggested to do backup first and then you can delete the backups once you figure it fixed issue and did not break anything)

# Reset VS Code’s webview partition data
base="$HOME/.config/Code"
stamp="$(date +%Y%m%d-%H%M%S)"

for item in \
  "Partitions" \
  "IndexedDB" \
  "Local Storage" \
  "WebStorage" \
  "Service Worker"
do
  if [ -e "$base/$item" ]; then
    mv "$base/$item" "$base/$item.backup-$stamp"
  fi
done

Probably only above are needed to be deleted, but I also deleted those cache files in the process

# Reset Codex profile state
base="$HOME/.config/Code"
stamp="$(date +%Y%m%d-%H%M%S)"

if [ -e "$base/User/globalStorage/openai.chatgpt" ]; then
  mv "$base/User/globalStorage/openai.chatgpt" \
     "$base/User/globalStorage/openai.chatgpt.backup-$stamp"
fi

# Clear the webview cache
base="$HOME/.config/Code"
stamp="$(date +%Y%m%d-%H%M%S)"

for item in \
  "Cache" \
  "Code Cache" \
  "GPUCache" \
  "Service Worker"
do
  if [ -e "$base/$item" ]; then
    mv "$base/$item" "$base/$item.codex-backup-$stamp"
  fi
done

Relaunch vscode multiple times

After clearing the cache, Codex did not load immediately on the first launch and during the next few launches, the console showed errors such as:

GET https://file+.vscode-resource.vscode-cdn.net/.../thread-page-header-CcULztl-.js net::ERR_FAILED

Uncaught (in promise) NetworkError:
Failed to execute 'put' on 'Cache':
Cache.put() encountered a network error

After restarting VS Code approximately three times, the webview cache appears to have rebuilt successfully and Codex loaded consistently.

---
My sidenote - I was running outdated codex versions in vscode because with them there was no issue with loading. However since gpt-5.6 is now available in codex and I prefer to use extension to cli, I really needed to fix the problem for me.

EDIT: I restarted notebook and it again did not load codex on first time... on second it did. I just hate this about codex.

FYI -- running codex features disable remote_plugin sets sth in the codex configurations that immediately fixed my extension loading problems.

Hitting the exact same signature here, but on a plain local install (no Remote-SSH, no code-server) — so this doesn't look like it's specific to the SSH/tunnel transport, more likely a race in the extension/app-server IPC layer itself.

Environment: Linux Mint 21.3 (Cinnamon), VS Code 1.128.0, extension openai.chatgpt 26.707.31428 (also reproduced on 26.707.41301), bundled codex-cli 0.144.0-alpha.4.

Symptom: Codex sidebar spins forever. Extension log:

[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

...then either silence forever, or shortly after:

[IpcClient] Initialize failed errorMessage=connection-closed errorName=Error errorStack="Error: connection-closed
	at Socket.<anonymous> (.../out/extension.js:546:17098)
	at Socket.emit (node:events:509:28)
	at Pipe.<anonymous> (node:net:351:12)"

Often with multiple [IpcRouter] I am the router lines firing within milliseconds of each other right before/after the failure, suggesting some kind of repeated re-election/reconnect race.

Running the bundled codex app-server binary directly and feeding it a hand-rolled initialize JSON-RPC message over stdio works fine in isolation — so the binary itself isn't broken, it's specifically the extension's connection/handshake to it that's flaky. With RUST_LOG=warn set (which the extension hardcodes when spawning the child), I got the underlying Rust side to log:

WARN codex_app_server::transport: dropping message for disconnected connection: ConnectionId(0)

right as the handshake fails — so app-server's own transport layer believes the connection is already gone by the time it tries to reply to initialize.

What partially helps, non-deterministically: killing any leftover codex ... app-server process, deleting the stale IPC socket (/tmp/codex-ipc/ipc-<uid>.sock) and lock files (~/.codex/app-server-daemon/*.lock), then Developer: Reload Window. This clears one real trigger (an orphaned app-server process from a previous session holding the shared socket), but the hang still recurs afterward even with a provably fresh process and no leftover state — so there's at least one more, deeper cause here beyond stale local state.