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

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