Codex VS Code extension loses chats after updates and freezes over Remote SSH

Codex VS Code extension intermittently fails to load chats and freezes over Remote SSH

Summary

The Codex extension for VS Code is currently unreliable and frequently unusable in my Remote SSH setup.

I use VS Code on Fedora Linux and connect to an Ubuntu Server 24.04 LTS system through the official Remote SSH extension. My projects, the Codex extension runtime, and Codex CLI are located on the Ubuntu server.

After Codex extension updates, existing conversations frequently appear to be missing, remain empty, or fail to load. In previous versions, uninstalling and reinstalling the extension several times sometimes restored access temporarily.

The issue has become more severe. Opening or starting a Codex conversation can now cause the conversation view to remain empty, make the remote extension host unresponsive, or freeze VS Code.

The Codex CLI on the same Ubuntu server works reliably and can open the same conversations using codex resume.

Environment

• Codex IDE extension: 26.707.71524
• Codex CLI: 0.144.1
• Subscription: ChatGPT Plus
• IDE: Visual Studio Code
• Local operating system: Fedora Linux
• Remote operating system: Ubuntu Server 24.04 LTS
• Connection: VS Code Remote SSH
• Remote SSH extension: 0.124.0
• Project location: Ubuntu server
• Codex extension runtime: Ubuntu server
• Codex CLI location: Ubuntu server

Steps to reproduce

1. Start VS Code on Fedora.
2. Connect to the Ubuntu server using VS Code Remote SSH.
3. Open a project located on the Ubuntu server.
4. Open the dedicated Codex sidebar or the VS Code Chat view.
5. Select an existing Codex conversation or start a new one.

Actual behavior

The behavior is intermittent:

• Existing conversations sometimes load correctly.
• Conversations sometimes open as completely empty views.
• Sometimes no loading indicator or error message appears.
• Sometimes VS Code or the remote extension host becomes unresponsive.
• After extension updates, existing conversations frequently appear to be missing or inaccessible.
• Reinstalling the Codex extension may temporarily restore access, but multiple reinstall attempts can be necessary.
• The same conversations remain accessible through codex resume in the Codex CLI.

Expected behavior

• Existing conversations should remain accessible after extension updates.
• The extension should load the same sessions that are available in Codex CLI.
• Conversations should load reliably in both the Codex sidebar and the VS Code Chat view.
• Starting or opening a conversation should not freeze VS Code or the remote extension host.
• Reinstalling the extension should not be necessary after updates.

Codex output log findings

During a successful conversation resume, the output contains:

maybe_resume_success
thread_stream_role_changed ... role=owner

However, the extension repeatedly reports IPC warnings:

[IpcClient] Received broadcast but no handler is configured method=client-status-changed
[IpcClient] Received broadcast but no handler is configured method=query-cache-invalidate
[IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed

There are also feature compatibility warnings between the extension and the spawned Codex app-server:

ignoring invalid experimental feature enablement keys: apps_mcp_path_override
codex_features: unknown feature key in config: thread_tools

When a conversation fails to load, the output stops after entries such as:

[IpcRouter] I am the router
[IpcClient] Received broadcast but no handler is configured method=client-status-changed
[IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed

In the failed case, the following successful resume messages are absent:

maybe_resume_started
maybe_resume_success
thread_stream_role_changed ... role=owner

VS Code Webview console findings

The VS Code Webview console shows a rapidly increasing listener count while Codex Webview resources are loaded:

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
potential listener LEAK detected, having 615 listeners already

The stack trace repeatedly points to Webview resource loading:

doReadFileStream
readFileStream
loadLocalResource
loadResource
webviewElement

After the listener count grows, Webview JavaScript and CSS resources sometimes fail to load:

network error response: insufficient resources
net::ERR_FAILED
Unable to preload CSS

Affected files include resources such as:

webview/assets/thread-layout-*.js
webview/assets/statsig-client-key-*.js
webview/assets/app-main-*.css
webview/assets/cmdk-*.css

VS Code then reports:

Extension host (Remote) is unresponsive.
Extension host (Remote) is responsive.
Extension host (Remote) is unresponsive.

The listener leak also occurs when only the dedicated Codex sidebar is open and the VS Code Chat view is closed. Sometimes the conversation still loads successfully before resource exhaustion occurs; at other times, the view remains empty.

Additional console messages

The console also reports:

PendingMigrationError: navigator is now a global in nodejs

This stack trace points to the Remote SSH extension:

ms-vscode-remote.remote-ssh-0.124.0

The Codex Webview additionally attempts to load a base64-encoded font that is blocked by its Content Security Policy:

Loading the font 'data:font/woff2;base64,...' violates the following Content Security Policy directive:
font-src 'self' https://*.vscode-cdn.net

These may be secondary issues, but I am including them for completeness.

IPC and sandbox checks

The Codex IPC directory and socket on the Ubuntu server appear normal:

/tmp/codex-ipc
owner: deltapapa
permissions: 0775
socket: ipc-1000.sock

Bubblewrap and the required Ubuntu AppArmor profile are installed. No bubblewrap, user namespace, sandbox creation, or permission errors appear in the Codex logs.

This therefore appears to be unrelated to the Linux sandbox configuration.

Current workaround

The reliable workaround is to use Codex CLI directly on the Ubuntu server:

cd /path/to/project
codex resume

The CLI can access the existing conversations and works reliably.

Reloading the VS Code window may temporarily restore the extension:

Developer: Reload Window

However, the problem returns.

Possible area of failure

Based on the logs, the issue may involve one or more of the following:

• Codex Webview resource loading under Remote SSH
• A listener or cancellation-handler leak in VS Code Webview resource handling
• IPC routing between the Codex app-server and Codex Webviews
• A version mismatch between the extension UI and the bundled Codex app-server
• Interaction between the Codex extension and the Remote SSH extension

The Codex CLI working correctly on the same server suggests that the conversations and Codex session storage themselves are valid.