VSCode + Remote SSH + Codex Extension hang at starting

I also tried to install older version of codex extension. Its the same.

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

• #14586
• #13848

Powered by Codex Action

Potential duplicates detected. Please review them and close your issue if it is a duplicate. Codex Extension does not show in VScode #14586 Codex fails to start/initialize in some directory trees #13848 _Powered by Codex Action_

Not the same issue as above.

Has there been any progress on this issue?

At this point, Codex is effectively unusable for me across multiple environments.

VS Code + Remote SSH

• When using the Codex extension over Remote SSH, the extension frequently freezes completely.
• I've tried reinstalling, clearing configuration, reconnecting, and various troubleshooting steps, but the behavior persists.
• Once it locks up, the extension becomes non-responsive and I have to restart components repeatedly.

Cursor + Remote SSH

• After pressing Enter, prompts often take anywhere from 45 seconds to 2 minutes before execution even begins.
• After a single successful prompt, the extension typically becomes unusable again.
• My current workaround is deleting the .codex folder, closing Cursor, reopening it, and logging in again before I can submit another prompt.
• Obviously, this is not a viable workflow.

Local Windows Usage

• The same stability problems exist locally.
• On a very high-end desktop, Codex regularly locks up every few prompts.
• I frequently observe behavior that appears consistent with excessive I/O wait or the extension becoming deadlocked.
• The UI becomes unresponsive and requires restarting to recover.

This isn't an isolated environment issue—I'm seeing similar failures across:

• VS Code
• Cursor
• Remote SSH sessions
• Local Windows installations

At the moment, reliability is poor enough that the extension cannot be used for day-to-day development work.

Could the team provide:

1. An update on whether these issues are actively being investigated?
2. Any known workarounds beyond repeatedly deleting local state and re-authenticating?
3. Guidance on collecting logs that would actually help identify the root cause?

I don't mean this disrespectfully, but it's surprising to see such severe stability issues persist across multiple platforms and environments. I'd be happy to help gather diagnostics if there's a path toward identifying what's causing these freezes.

<img width="1248" height="503" alt="Image" src="https://github.com/user-attachments/assets/0f6eb636-7262-4b44-904f-604d6e716eaf" />5 minutes later still hasn't done anything.

the same issue

Diagnosis and workaround for Codex VS Code sidebar hang in Remote-SSH / local VS Code

I hit a similar issue where the Codex VS Code extension sidebar did not load, while the Codex CLI worked normally from both the VS Code integrated terminal and a normal SSH/iTerm session.

Environment

• VS Code: 1.126.0
• Remote host: Ubuntu 24.04, Alibaba Cloud Singapore region
• Codex / ChatGPT extension: openai.chatgpt-26.5623.61825-linux-x64
• Scenario: VS Code Remote-SSH
• Symptom:
• Codex: Open Codex Sidebar opens the Codex sidebar, but the UI never finishes loading.
• Eventually VS Code shows:

``text
The window is not responding
You can reopen or close the window or keep waiting
``

• VS Code itself is still usable after clicking Keep Waiting.
• codex CLI works normally in terminal.
• Codex: New Codex Agent may still work, while the sidebar remains stuck.

Important observations

The Codex extension backend was not the root cause. The app-server started normally:

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

The codex app-server process was alive:

ps -ef | grep -i '[c]odex'

IPC was also not the root cause. /tmp/codex-ipc/ipc-1001.sock existed, had the correct owner, and was listened to by the VS Code remote extension host:

ls -la /tmp/codex-ipc
ss -xlpn | grep -E 'codex-ipc|ipc-1001'

There were warnings like this:

codex_core_plugins::manifest: ignoring interface.defaultPrompt[0]: prompt must be at most 128 characters
path=/home/<user>/.codex/.tmp/plugins/plugins/ngs-analysis/.codex-plugin/plugin.json

However, this did not appear to be the direct cause. Removing plugin cache / catalog did not fix the sidebar issue.

Claude Code was also not the root cause. I disabled Claude Code, killed stale Claude processes, restarted the extension host, and the Codex sidebar issue still reproduced.

Actual failure pattern

The decisive signal came from Developer: Open Webview Developer Tools while the Codex sidebar was stuck.

The console showed repeated VS Code webview resource loader listener leak warnings:

ERR potential listener LEAK detected
at xle.doReadFileStream
at xle.readFileStream
at s4o (resourceLoading.ts)
at B3e.loadResource (webviewElement.ts)

The listener count kept increasing:

potential listener LEAK detected, having 175 listeners already
potential listener LEAK detected, having 263 listeners already
potential listener LEAK detected, having 351 listeners already
potential listener LEAK detected, having 439 listeners already
potential listener LEAK detected, having 527 listeners already

The stack was consistently in VS Code's webview local resource loading path:

doReadFileStream
readFileStream
loadLocalResource
webviewElement.loadResource

The repeated resources were Codex extension webview chunks such as:

webview/assets/dictation-error-message-*.js
webview/assets/remote-control-enable-error-*.js
webview/assets/codex-api-error-*.js
webview/assets/error-boundary-*.js
webview/assets/use-auth-*.js

This suggests the issue is not Codex CLI, auth, remote networking, IPC, or codex app-server. It is more likely a corrupted/stale VS Code webview/sidebar view state or webview resource loader state for the Codex sidebar.

Working recovery sequence

The recovery that worked was:

1. In the affected VS Code window, run:

``text
Developer: Reload Webviews
``

1. Then run:

``text
Developer: Reload Window
``

1. Then reset VS Code view layout state:

``text
View: Reset View Locations
``

1. Then run again:

``text
Developer: Reload Window
``

1. Before opening the sidebar, verify the editor-panel path:

``text
Codex: New Codex Agent
``

This should open a normal editor panel and reach the input box.

1. Then open the sidebar again:

``text
Codex: Open Codex Sidebar
``

After this sequence, the Codex sidebar recovered.

The same sequence also fixed the local VS Code sidebar after the Remote-SSH instance had been fixed. This indicates the local and remote VS Code Codex states are independent:

Remote-SSH Codex state:
~/.vscode-server/extensions/openai.chatgpt-...
~/.vscode-server/data/...

Local Codex state:
~/.vscode/extensions/openai.chatgpt-...
~/Library/Application Support/Code/...

What did not fix it

The following did not solve the issue by itself:

• Killing only codex app-server
• Removing /tmp/codex-ipc
• Removing ~/.codex/.tmp/plugins
• Removing ~/.codex/cache/remote_plugin_catalog
• Disabling Claude Code
• Restarting only the extension host
• Moving Codex from secondary sidebar to activity bar by patching extension package.json
• Re-authing Codex CLI

Practical workaround

If the sidebar is stuck but the editor panel works, use:

Codex: New Codex Agent

as a temporary workaround.

Avoid repeatedly opening the broken sidebar, because it can trigger repeated webview local resource loads and eventually VS Code's renderer watchdog.

Summary

The failure mode appears to be:

Codex CLI: OK
codex app-server: OK
IPC socket: OK
Codex editor panel webview: OK
Codex sidebar webview: stuck
VS Code webview resource loader: listener leak / stale view state

The effective fix was to reset the VS Code webview and view-layout state:

Developer: Reload Webviews
Developer: Reload Window
View: Reset View Locations
Developer: Reload Window

the same issue

You may try the fix path I just committed.