›_ Codex Issues
Codex Issues / #31633

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

Open 💬 4 comments Opened Jul 8, 2026 by jarube
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

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

  • #31149

Powered by Codex Action

jarube · 1 month ago

Thanks for the duplicate suggestion. I reviewed #31149 and it does look related, especially around thread-stream-state-changed broadcast floods and Codex/VS Code extension performance.

I do not think this report is an exact duplicate, unless maintainers prefer to consolidate these under one tracking issue:

  • #31149 is a Windows/local VS Code case where the Codex webview does not mount (React root render requested, app routes mounted, and ready are absent), and the user sees a blank/unusable panel.
  • This issue is a VS Code Remote SSH case where the Codex webview does mount, a simple prompt submit succeeds, Conversation created is logged, and title generation completes with status=success.
  • The failure here is sustained post-submit CPU churn in the remote extensionHost and spawned codex app-server, captured with top and vmstat.
  • This issue also includes a stable control build (26.422.21459) and two failing builds (26.616.32156, 26.623.141536) tested in the same disposable remote environment with rollback between runs.

So I suspect the underlying area may be shared (thread-state broadcast handling / feature negotiation / app-server compatibility), but the observed failure mode and reproduction path are different enough that this may be useful as a separate repro.

splitice · 1 month ago

Downgrade to 26.506.31421 which for me is the last known working version

jarube · 1 month ago

Follow-up after testing openai.chatgpt@26.506.31421 in the same disposable VS Code Remote SSH environment.

This was tested because another user mentioned 26.506.31421 as their last known working version.

Setup notes:

  • Rolled the disposable remote test container back to the clean 26.422.21459 baseline first.
  • Installed openai.chatgpt@26.506.31421 on the remote side.
  • The test container is cloned, so the old ~/.codex/auth.json initially failed with a reused refresh token. I moved that CT107 auth state aside and re-authenticated with codex login --device-auth.
  • Cleaned up duplicate stale remote extensionHost / codex app-server processes after reload/login attempts so the final measurement had 1 extensionHost and 1 app-server.

Observed result:

  • Prompt: test ok
  • Conversation created: 019f5067-f472-7c23-80da-208bd4ecedf4
  • The local rollout file completed successfully: ~/.codex/sessions/2026/07/11/rollout-2026-07-11T09-00-17-019f5067-f472-7c23-80da-208bd4ecedf4.jsonl
  • Final assistant message in the rollout: Test received, all good.
  • Duration was about 2.2s.

However, the VS Code Codex webview on the Windows desktop stayed stuck on the thinking state (Denkt na) and did not render the final assistant response.

Resource behavior was much better than 26.616/26.623:

  • extensionHost RSS: about 1047 MiB
  • codex app-server RSS: about 100-104 MiB
  • measured VS Code/Codex CPU: 0%
  • total RAM: about 1.45-1.52 GiB
  • swap near zero

Relevant log signatures still present:

unsupported feature enablement `workspace_dependencies`
failed to read OAuth tokens from keyring: Platform secure storage failure: no secret service provider or dbus session found
AuthRequired
codex_rollout::list: state db discrepancy during find_thread_path_by_id_str_in_subdir: falling_back

So in this environment 26.506.31421 does not reproduce the CPU churn from 26.616.32156 / 26.623.141536, but it is still not a clean Remote SSH fix: the backend completes while the VS Code webview remains stuck and misses the final thread/update.