macOS VS Code extension: open-in-targets / set-preferred-app throws cause sustained high CPU and heat

What version of the IDE extension are you using?

26.409.20454

What subscription do you have?

Pro

Which IDE are you using?

VS Code

What platform is your computer?

Darwin arm64 macOS 15.3

What issue are you seeing?

CPU stays elevated and the machine heats up while the Codex VS Code extension is active.

I traced this to the packaged extension bundle and found these handlers in out/extension.js still throw in extension mode:

"open-in-targets": async () => { throw new Error("open-in-target not supported in extension") },
"set-preferred-app": async () => { throw new Error("open-in-target not supported in extension") },

In my local testing, replacing them with empty success values immediately stopped the CPU/heat problem:

"open-in-targets": async () => ({ targets: [], availableTargets: [], preferredTarget: null }),
"set-preferred-app": async () => ({}),

After that change, CPU usage returned to normal and the machine stopped heating up. This suggests the repeated exceptions in extension mode are likely causing log/retry/error churn rather than the unsupported feature itself being the main issue.

What steps can reproduce the bug?

1. Install/open the Codex IDE extension in VS Code on macOS.
2. Open the Codex panel and use it normally.
3. In my case, the issue was easy to notice after the settings UI or file/diff related UI had been used.
4. Observe sustained CPU usage and machine heat.
5. Inspect the packaged extension and note that open-in-targets / set-preferred-app throw in extension mode.
6. Replace those throws locally with empty return values and reload VS Code.
7. Observe that CPU usage returns to normal.

What is the expected behavior?

Unsupported open-target functionality in the VS Code extension should degrade gracefully. Returning an empty capability response should not cause sustained CPU usage, repeated exception churn, or thermal issues.

Additional information

Related issues that appear close to this symptom family: #16849, #16850, #15397, #15393.

One additional reason I think returning an empty object is the right behavior here: the webview/settings side already appears able to tolerate empty values like targets ?? [], so throwing from the extension host seems unnecessarily expensive.