VS Code Remote SSH: Codex extension 26.616/26.623 causes sustained extensionHost and app-server CPU churn; 26.422 baseline remains stable

What version of the IDE extension are you using?

Tested:

• openai.chatgpt-26.422.21459-linux-x64: stable baseline
• openai.chatgpt-26.616.32156-linux-x64: reproduces CPU churn
• openai.chatgpt-26.623.141536-linux-x64: reproduces CPU churn

Which IDE are you using?

VS Code Stable 1.128.0, using Remote SSH from Windows desktop to a Linux remote.

What platform is your computer?

Local:

• Windows desktop client
• VS Code Remote SSH

Remote:

• Debian LXC on Proxmox
• x86_64
• 4 vCPU exposed to the container
• 12 GiB RAM
• 2 GiB swap
• test container cloned from a known-good production remote, used only for

disposable update testing

What issue are you seeing?

In a VS Code Remote SSH workspace, newer Codex VS Code extension builds can
successfully activate and send a simple message, but then enter sustained CPU
churn in both the VS Code remote extensionHost and the spawned codex
app-server.

The same remote workspace remains stable on openai.chatgpt-26.422.21459.

Steps to reproduce

1. Start from a clean Remote SSH Linux environment with

openai.chatgpt-26.422.21459-linux-x64.

1. Open VS Code from a Windows desktop over Remote SSH.
2. Open a normal git workspace.
3. Open the Codex panel.
4. Send a simple prompt such as test ok.
5. Confirm the baseline is stable.
6. Install openai.chatgpt@26.616.32156 or openai.chatgpt@26.623.141536

on the remote side.

1. Run Developer: Reload Window.
2. Open Codex again and send test ok.
3. Observe CPU with top -b -n 4 -d 2 and vmstat 2 8.

Expected behavior

After a simple completed prompt, the remote extension host and Codex app-server
should return to near-idle CPU, similar to the 26.422.21459 baseline.

Actual behavior

Both 26.616.32156 and 26.623.141536 complete a simple prompt and title
generation, but then show sustained CPU churn.

Stable baseline: 26.422.21459

After rollback to the clean baseline:

• active runtime:

openai.chatgpt-26.422.21459-linux-x64/bin/linux-x86_64/codex app-server

• extensionHost: about 172-215 MiB RSS
• total RAM used: about 450-750 MiB
• swap: 0
• measured CPU: 0%
• local health check: OK

Repro 1: 26.623.141536

Functional result:

• prompt submit worked
• Conversation created
• title generation completed with status=success

Resource behavior:

• extensionHost RSS: about 950-976 MiB
• codex app-server RSS: about 120 MiB
• top peaks:
• extensionHost: about 99% CPU
• codex app-server: about 75% CPU
• vmstat 2 6 after stopping unrelated monitoring loop:
• user CPU: about 34-37%
• system CPU: about 8-11%
• load average reached about 4.24, 3.45, 2.63
• RAM and swap stayed manageable, but CPU did not return to healthy idle

Representative log signatures:

Features enabled enabledFeatures="... workspace_dependencies ... thread_tools ... apps_mcp_path_override ..."
codex_app_server::request_processors::config_processor: ignoring invalid experimental feature enablement keys: apps_mcp_path_override
codex_features: unknown feature key in config: thread_tools
[IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed
codex_rollout::list: state db discrepancy during find_thread_path_by_id_str_in_subdir: falling_back

Repro 2: 26.616.32156

Functional result:

• prompt submit worked
• Conversation created
• title generation completed with status=success

Resource behavior:

• extensionHost RSS: about 968 MiB
• codex app-server RSS: about 136 MiB
• top peaks:
• extensionHost: about 100% CPU
• codex app-server: about 64-73% CPU
• vmstat 2 8:
• user CPU: about 33-37%
• system CPU: about 7-9%
• RAM and swap stayed manageable, but CPU did not return to healthy idle

Representative log signatures:

Features enabled enabledFeatures="... workspace_dependencies ... thread_tools ... apps_mcp_path_override ..."
codex_app_server::request_processors::config_processor: ignoring invalid experimental feature enablement keys: apps_mcp_path_override
codex_features: unknown feature key in config: thread_tools
[IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed
codex_rollout::list: state db discrepancy during find_thread_path_by_id_str_in_subdir: falling_back

Additional notes

• ps %CPU and Proxmox pvesh ... status/current can miss the hot loop in

this case; top -b and vmstat captured it reliably.

• The Remote SSH test environment is disposable. After each failed update test,

the container was rolled back to a clean snapshot.

• This looks related to feature negotiation / app-server compatibility and

thread state broadcast handling rather than project indexing or workspace
workload.

• The older 26.422.21459 build remains the only stable VS Code Remote SSH

baseline in this environment.

Related issues that look similar

• Feature negotiation mismatch where JS requests features unsupported by the

Rust app-server.

• thread_tools unknown feature key crashes/warnings.
• thread-stream-state-changed snapshot/broadcast CPU churn.
• Remote extension host instability in newer builds while older builds have

other submit/state issues.