VS Code extension spikes CPU and logs "open-in-target not supported in extension" while rendering diffs after Codex edits files

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

• #16849
• #16320
• #15397
• #15958
• #15330

Powered by Codex Action

I've encountered the same problem.

After using the latest version of the CodeX vs Code extension and having several conversations with CodeX,

my Macbook Air M4's CPU usage exceeded 100%, and the computer overheated significantly.

@MingLi3306
You can try this:

具体修复思路

修改文件：

• /Users/你的用户名称/.vscode/extensions/openai.chatgpt-26.325.31654-darwin-arm64/webview/assets/index-CpiKkRDN.js

在打包后的 bundle 中，定位这一段逻辑：

// 原逻辑：无论当前窗口是 electron 还是 VS Code extension，
// 都会去请求 open-in-targets。
//
// 这段代码的本意是：查询“当前 cwd 有哪些可用的打开目标（target）”，
// 供 diff 界面决定是否展示额外打开方式、默认 target 等信息。
//
// 问题在于：在 VS Code extension 模式下，宿主端并不支持这个接口，
// 调用后会直接抛出 "open-in-target not supported in extension"。
// 因此原代码在 extension 中会持续触发失败请求。
queryFn:async()=>Je(`open-in-targets`,{params:{cwd:e}})

把它改成：

// 修改后：只在 electron 窗口中才真正请求 open-in-targets。
//
// 如果当前窗口是 electron：
// 仍然保持原行为，继续向宿主端查询 open target 列表。
//
// 如果当前窗口是 VS Code extension：
// 直接返回一个“空结果”对象，而不是再去调用那个不支持的接口。
// 这样后续 UI 仍然可以正常工作，只是表示“没有额外 target 可选”，
// 从而避免 unsupported API 报错、日志风暴和额外渲染开销。
queryFn:async()=>document.documentElement.dataset.codexWindowType==="electron"
  ? Je(`open-in-targets`,{params:{cwd:e}})
  : {preferredTarget:null,targets:[],availableTargets:[]}

这样修改后：

• 如果当前窗口是 electron，仍然走原逻辑
• 如果当前窗口是 extension，直接返回空结果，不再触发宿主端 unsupported API

run this script to fix it

set -euo pipefail

EXT_DIR="$HOME/.vscode/extensions"
PATCHED=0
SKIPPED=0
ALREADY=0

find "$EXT_DIR" -maxdepth 1 -type d -name "openai.chatgpt-*" | sort | while read -r dir; do
  ext_js="$dir/out/extension.js"
  version=$(basename "$dir")

  if [[ ! -f "$ext_js" ]]; then
    echo "[$version] extension.js not found, skipping"
    continue
  fi

  # Check if bug is present
  if grep -q '"open-in-targets":async()=>{throw new Error("open-in-target not supported in extension")}' "$ext_js"; then
    echo "[$version] bug detected — patching..."

    # Backup (only once per version)
    if [[ ! -f "$ext_js.bak" ]]; then
      cp "$ext_js" "$ext_js.bak"
      echo "[$version] backup created: extension.js.bak"
    fi

    sed -i '' \
      's/"open-in-targets":async()=>{throw new Error("open-in-target not supported in extension")}/"open-in-targets":async()=>({targets:[]})/g' \
      "$ext_js"

    sed -i '' \
      's/"set-preferred-app":async()=>{throw new Error("open-in-target not supported in extension")}/"set-preferred-app":async()=>({})/g' \
      "$ext_js"

    # Verify
    if grep -q '"open-in-targets":async()=>({targets:\[\]})' "$ext_js"; then
      echo "[$version] patched successfully"
    else
      echo "[$version] patch verification failed — restoring backup"
      cp "$ext_js.bak" "$ext_js"
    fi

  elif grep -q '"open-in-targets":async()=>({targets:\[\]})' "$ext_js"; then
    echo "[$version] already patched, skipping"
  else
    echo "[$version] open-in-targets pattern not found — extension structure may have changed"
  fi
done

echo ""
echo "Done. Reload VS Code windows to apply: Cmd+Shift+P → Developer: Reload Window"

related to https://github.com/openai/codex/issues/16849

@MingLi3306 You can try this: ### 具体修复思路 修改文件： /Users/你的用户名称/.vscode/extensions/openai.chatgpt-26.325.31654-darwin-arm64/webview/assets/index-CpiKkRDN.js 在打包后的 bundle 中，定位这一段逻辑： // 原逻辑：无论当前窗口是 electron 还是 VS Code extension， // 都会去请求 open-in-targets。 // // 这段代码的本意是：查询“当前 cwd 有哪些可用的打开目标（target）”， // 供 diff 界面决定是否展示额外打开方式、默认 target 等信息。 // // 问题在于：在 VS Code extension 模式下，宿主端并不支持这个接口， // 调用后会直接抛出 "open-in-target not supported in extension"。 // 因此原代码在 extension 中会持续触发失败请求。 queryFn:async()=>Je(open-in-targets,{params:{cwd:e}}) 把它改成： // 修改后：只在 electron 窗口中才真正请求 open-in-targets。 // // 如果当前窗口是 electron： // 仍然保持原行为，继续向宿主端查询 open target 列表。 // // 如果当前窗口是 VS Code extension： // 直接返回一个“空结果”对象，而不是再去调用那个不支持的接口。 // 这样后续 UI 仍然可以正常工作，只是表示“没有额外 target 可选”， // 从而避免 unsupported API 报错、日志风暴和额外渲染开销。 queryFn:async()=>document.documentElement.dataset.codexWindowType==="electron" ? Je(open-in-targets,{params:{cwd:e}}) : {preferredTarget:null,targets:[],availableTargets:[]} 这样修改后： 如果当前窗口是 electron，仍然走原逻辑 * 如果当前窗口是 extension，直接返回空结果，不再触发宿主端 unsupported API

Thank you for your help.

+1

Facing the same issue. As soon as I start the VS Code extension and ask anything, the CPU usage jumps to 100% and the fan throttles heavily. This is strange, as I didn’t experience this earlier. Also the thing is when is running the cpu spikes and when is done working then the cpu usage goes down. For long task it just makes it very inconvenient.

codex vs-code extension: 26.5401.11717
macOS 26.3.1
Visual Studio Code: Version: 1.114.0

<img width="385" height="79" alt="Image" src="https://github.com/user-attachments/assets/b915f9e7-6269-428e-b464-4433be5300dd" />

+1 Facing the same issue. As soon as I start the VS Code extension and ask anything, the CPU usage jumps to 100% and the fan throttles heavily. This is strange, as I didn’t experience this earlier. Also the thing is when is running the cpu spikes and when is done working then the cpu usage goes down. For long task it just makes it very inconvenient. codex vs-code extension: 26.5401.11717 macOS 26.3.1 Visual Studio Code: Version: 1.114.0 <img alt="Image" width="385" height="79" src="https://private-user-images.githubusercontent.com/95222112/574586863-b915f9e7-6269-428e-b464-4433be5300dd.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzU2MjE4MTQsIm5iZiI6MTc3NTYyMTUxNCwicGF0aCI6Ii85NTIyMjExMi81NzQ1ODY4NjMtYjkxNWY5ZTctNjI2OS00MjhlLWI0NjQtNDQzM2JlNTMwMGRkLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA0MDglMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwNDA4VDA0MTE1NFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWMzMWNmODEwZTVkNjdiYWI4NWZkYWY0OTk1MDYxN2ExMGIyN2YwOWVmMmY2MzMwZjM4OTU3OWUyNmJhZjlhMmImWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.ogu2heTfuZnwc2E5Aoa0ref5BhUhCTEYIkBa2K1S2HA">

cek https://github.com/openai/codex/issues/16849

@shx2005, I can confirm this appears to be the same bug family, and I reproduced it on a fresh Debian Linux install with only GNOME, Git, VS Code, and the OpenAI extension installed. See Issue 17357.

My observed signatures matched yours:

• open-in-target not supported in extension
• local-environments is not supported in the extension
• [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed

On my side, the issue also caused persistent CPU churn until VS Code was fully closed.

What seems especially useful for triage is that I ran a reversible local hotfix experiment against the installed extension bundle:

1. I patched out the original thread-stream-state-changed / local-environments failure paths.
2. After restart, those exact signatures dropped to zero.
3. The extension still stayed broken and immediately shifted to hammering another unsupported route:

• vscode://codex/open-in-targets
• roughly 1569 occurrences over 8.487 seconds in one sampled burst
• about 184.75 errors/sec in that burst

That result made me think this is broader than one isolated endpoint and more likely a capability-gating mismatch where extension-mode UI/webview code is still exercising host routes that the extension host explicitly marks unsupported.

I also inspected the shipped bundle and found a larger cluster of handlers that explicitly throw as unsupported in extension mode, 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

So my guess is the extension is not properly disabling or gating one or more feature families after discovering the host is running in VS Code extension mode.

Follow-up on Debian Linux: the issue reproduced again after the extension auto-updated from 26.406.31014 to 26.409.20454, so the update did not fix it upstream.

In 26.409.20454 I still observed:

• 679x open-in-target not supported in extension
• at least one thread-stream-state-changed unhandled broadcast warning
• elevated CPU in the VS Code extension-host tree

I then reapplied the same broad local hotfix strategy to the new bundle and restarted VS Code. After that:

• open-in-target errors disappeared from the active session log
• local-environments errors disappeared
• the persistent runaway churn no longer appears present
• only a few thread-read-state-changed warnings remain

That makes me more confident the core issue is an unsupported-host capability mismatch and that the repeated unsupported route failures were the main driver of the persistent CPU storm.

Confirmed on Windows as well.

User-visible symptom in my case:

• file links in Codex chat do not open in the editor
• earlier they sometimes opened in the browser instead
• now they often do nothing

Local extension log shows:

• open-in-target not supported in extension
• local-environments is not supported in extension
• url=vscode://codex/open-in-targets

Environment:

• VS Code 1.115.0
• Codex extension openai.chatgpt 26.5409.20454
• launch args:
• --user-data-dir "C:\VSCode\settings\Default1"
• --extensions-dir "C:\VSCode\extensions\Default"

So for me this is not only a CPU/logging issue, but also a broken file-link-opening issue in the Codex chat UI.

Check https://github.com/openai/codex/issues/15330#issuecomment-4248241733

Confirming this still happens on openai.chatgpt-26.409.20454-darwin-arm64 — 84 versions newer than OP's report — and now also affects Google Antigravity (a VS Code fork), not just official VS Code.

Repro environment

• Antigravity (Google's VS Code fork) on macOS 26.4.1 (Apple Silicon)
• Extension version: openai.chatgpt-26.409.20454
• Two windows open with Codex sidebar active

Observed

• open-in-target not supported in extension errors at 142/sec (peak)
• 9,834 errors per window over ~1 hour, filling 6×5MB rolling log files
• Two Renderer processes (main UI + webview) burning 119% + 68% CPU
• Load Avg 8.84, system idle dropped to 58%

Fix verified

Applied OP's patch via direct edit of the bundled out/extension.js (replacing both throw new Error(...) handlers with safe empty responses):

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

After full restart of Antigravity:

• New session logs: 0 instances of the error
• Log volume: 36 MB → 12 KB for the same time window
• Renderer CPU: 119% → 3.3%
• Load Avg: 8.84 → 2.91, idle 58% → 90.92%

Functional impact: the "Open in External App" right-click flow is the only thing that breaks. Chat, code edits, command execution all work normally.

This is also a strong signal that the bug is in the webview's React Query side, not just the host handler — patching the host to return empty is a sufficient workaround because the webview's retry loop stops once it gets a non-error response.

I can reproduce this issue consistently on macOS (Apple Silicon).

codex extension version: 26.409.20454
feedback id: 019d94b8-2535-71d1-80a3-aa9701d9c2c9

Additional observations that may help:

• The high CPU usage happens even when the Codex chat panel is idle (no interaction at all)
• Code Helper (Renderer) process goes up to ~180% CPU
• Closing the chat panel immediately drops CPU usage back to normal

In the VS Code Output panel (Codex), I see repeated errors like:

Error: open-in-target not supported in extension
url=vscode://codex/open-in-targets

This suggests the WebView might be repeatedly attempting to call
an unsupported command, possibly causing a retry loop or continuous re-render.

This might explain why the renderer process consumes high CPU even when idle.

run this script to fix it `` set -euo pipefail EXT_DIR="$HOME/.vscode/extensions" PATCHED=0 SKIPPED=0 ALREADY=0 find "$EXT_DIR" -maxdepth 1 -type d -name "openai.chatgpt-*" | sort | while read -r dir; do ext_js="$dir/out/extension.js" version=$(basename "$dir") if [[ ! -f "$ext_js" ]]; then echo "[$version] extension.js not found, skipping" continue fi # Check if bug is present if grep -q '"open-in-targets":async()=>{throw new Error("open-in-target not supported in extension")}' "$ext_js"; then echo "[$version] bug detected — patching..." # Backup (only once per version) if [[ ! -f "$ext_js.bak" ]]; then cp "$ext_js" "$ext_js.bak" echo "[$version] backup created: extension.js.bak" fi sed -i '' \ 's/"open-in-targets":async()=>{throw new Error("open-in-target not supported in extension")}/"open-in-targets":async()=>({targets:[]})/g' \ "$ext_js" sed -i '' \ 's/"set-preferred-app":async()=>{throw new Error("open-in-target not supported in extension")}/"set-preferred-app":async()=>({})/g' \ "$ext_js" # Verify if grep -q '"open-in-targets":async()=>({targets:\[\]})' "$ext_js"; then echo "[$version] patched successfully" else echo "[$version] patch verification failed — restoring backup" cp "$ext_js.bak" "$ext_js" fi elif grep -q '"open-in-targets":async()=>({targets:\[\]})' "$ext_js"; then echo "[$version] already patched, skipping" else echo "[$version] open-in-targets pattern not found — extension structure may have changed" fi done echo "" echo "Done. Reload VS Code windows to apply: Cmd+Shift+P → Developer: Reload Window" `` related to #16849

this doesn't work with version above .409. , this fix is obsolete

Update regarding my earlier comment: https://github.com/openai/codex/issues/16850#issuecomment-4235816327

My issue appears to be resolved now.

In my case this was on Windows with VS Code Insiders + the Codex extension, behind a corporate proxy. VS Code already had http.proxy configured, and the usual HTTP_PROXY / HTTPS_PROXY environment variables were already set, but WinHTTP was still configured for direct access:

netsh winhttp show proxy
I fixed it by running an elevated PowerShell and importing the Windows/IE proxy settings into WinHTTP:

powershell

netsh winhttp import proxy source=ie
netsh winhttp show proxy
After that, WinHTTP showed the corporate proxy. I restarted VS Code Insiders, and the Codex extension became fast again. Clicking source-file links from Codex chat now opens the files correctly as well.

I tested links to .ps1, .md, and other workspace source files. I also checked the VS Code/Codex logs after testing, and I no longer see new occurrences of:

text


open-in-target not supported in extension
vscode://codex/open-in-targets
local-environments is not supported
So for my environment, VS Code http.proxy alone was not enough. The missing piece was the WinHTTP proxy configuration. This may be useful for other Windows/corporate-proxy cases where the Codex extension is slow or where local file/link operations behave strangely.