bug: VS Code extension enters persistent CPU churn by repeatedly calling unsupported host endpoints (`local-environments`, `open-in-targets`) on fresh Debian

What version of the IDE extension are you using?

OpenAI VS Code extension openai.chatgpt / Codex version 26.406.31014

What subscription do you have?

Plus

Which IDE are you using?

VS Code

What platform is your computer?

Linux 6.19.11+deb14-amd64 x86_64 unknown

What issue are you seeing?

The OpenAI VS Code Codex extension enters a persistent hot state and churns CPU until VS Code is fully closed.

This appears to be caused by the extension repeatedly invoking host endpoints that the same extension build explicitly marks as unsupported.

I investigated this locally and confirmed two phases of the bug:

1. Initial failure mode:

• repeated unhandled IPC broadcast warnings for thread-stream-state-changed
• repeated local-environments is not supported in the extension

1. After a reversible local hotfix that suppressed those exact paths:

• those original signatures dropped to zero
• the extension immediately began hammering a different unsupported route instead:

vscode://codex/open-in-targets

The latest log shows the new failure mode at very high rate:

• open-in-target not supported in extension
• approximately 1569 occurrences over 8.487 seconds
• roughly 184.75 errors per second in one sampled burst

This strongly suggests a broader capability-gating mismatch between the webview / frontend and the extension-host request dispatcher. The caller appears to retry unsupported routes aggressively instead of backing off or disabling the feature.

What steps can reproduce the bug?

On my machine, the rough reproduction pattern is:

1. Fresh Debian install with GNOME and Git.
2. Install VS Code stable.
3. Install only the OpenAI VS Code extension.
4. Open a workspace and activate the Codex sidebar / extension.
5. Interact with Codex in the workspace until it begins normal activity.
6. CPU churn begins and persists until VS Code is fully closed.

Important detail:

• this is not just one broken route
• after I patched away the first observed broken paths, the extension stayed broken and shifted to another unsupported endpoint

What is the expected behavior?

The extension should:

• only enable host-integrated features that are actually supported in this extension-host environment
• not repeatedly call unsupported endpoints
• not enter a high-rate retry loop
• not consume sustained CPU after a route fails

Additional information

I attached evidence with:

• revised and original bug reports

openai-codex-vscode-bug-report-2026-04-10.md

openai-codex-vscode-bug-report-2026-04-10-revised.md

Key conclusions from the investigation:

1. thread-stream-state-changed unhandled broadcasts were real.
2. local-environments is not supported in the extension was real.
3. After suppressing those exact paths, the extension still stayed broken.
4. The next dominant loop became open-in-targets.
5. Therefore this is likely not a one-off bug but a broader unsupported-host capability mismatch.

I also inspected the compiled extension bundle and found a cluster of host routes that explicitly throw as unsupported in this extension build, including:

• open-in-targets
• set-preferred-app
• local-environment-config
• local-environment-config-save
• workspace-directory-entries
• remote-workspace-directory-entries
• worktree-create-managed
• worktree-delete
• worktree-set-owner-thread

This looks like the UI or IPC layer may be exercising capabilities that the host dispatcher knows are unavailable.