VS Code Remote-SSH: bundled CLI rejects thread_tools and extension floods logs with unhandled app-server broadcasts

Open 💬 5 comments Opened Jun 16, 2026 by lz5db

What version of the IDE extension are you using?

26.609.30741

What subscription do you have?

ChatGPT Plus

Which IDE are you using?

Visual Studio Code 1.124.2 with Remote-SSH

What platform is your computer?

Local VS Code client: Windows 10 Pro x64, Remote extension host: Ubuntu 24.04 LTS (noble), Linux x86_64

What issue are you seeing?

The Codex VS Code extension works through Remote-SSH and can execute commands, but the extension and its bundled app-server/CLI appear internally incompatible.

Environment
VS Code extension: openai.chatgpt-26.609.30741-linux-x64
Bundled Codex CLI: codex-cli 0.140.0-alpha.2
IDE: Visual Studio Code 1.124.2
Connection: Remote-SSH
Remote OS: Ubuntu 24.04 LTS, x86_64
Authentication: ChatGPT account
Subscription: ChatGPT Plus

The active app-server executable is:

~/.vscode-server/extensions/openai.chatgpt-26.609.30741-linux-x64/bin/linux-x86_64/codex

What steps can reproduce the bug?

Reproduction steps
Open a VS Code Remote-SSH session.
Reload the VS Code window.
Start a new Codex conversation.
Send a minimal prompt such as:
Reply with OK only.
Inspect the Codex extension log.
Actual behavior

The extension enables thread_tools:

Features enabled enabledFeatures="..., thread_tools, ..."

However, its bundled CLI rejects the same feature:

codex_features: unknown feature key in config: thread_tools

During every new conversation, the extension emits many warnings such as:

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

A new conversation also emits:

codex_rollout::list: state db discrepancy during find_thread_path_by_id_str_in_subdir: falling_back

However, codex doctor reports that the local state is healthy:

state databases healthy
threads rollout files and state DB thread inventory agree
rollout DB missing active rows 0
rollout DB stale rows 0
rollout DB duplicate rollout thread ids 0
rollout DB duplicate DB paths 0

All recorded rollout paths exist, and SQLite integrity checks pass.

What is the expected behavior?

The extension should not enable a feature unsupported by its bundled CLI.
App-server broadcasts used during normal conversation execution should have registered handlers.
A healthy thread database should not repeatedly trigger a discrepancy fallback.
Starting a minimal conversation should not generate a high-volume warning flood.

Additional information

Additional observations

The bundled curated plugin marketplace also contains an invalid manifest for an uninstalled plugin:

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

Automatic title generation for a minimal conversation consumed approximately 22,500 input tokens:

feature=thread_title
model=gpt-5.4-mini
inputTokens=22585
cachedInputTokens=19968

Ubuntu 24.04 AppArmor initially caused Bubblewrap to fail with:

bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

The sandbox currently works using this temporary compatibility setting:

[features]
use_legacy_landlock = true

That workaround fixes sandbox execution but does not affect the unsupported feature or unhandled IPC warnings.

A redacted diagnostic report containing the extension version, CLI version, doctor --summary, feature state, and representative log lines is attached.

codex-vscode-diagnostic-20260616T014526Z.txt

View original on GitHub ↗

This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗