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

What issue are you seeing?

When Codex edits code in the VS Code extension and starts rendering the Git diff / thread UI, CPU usage spikes and the machine heats up noticeably.

This does not appear to be caused by the prompt itself. It happens when the response includes file edits and the extension renders the resulting diff UI, especially for multi-file edits.

The extension host logs are filled with these errors/warnings:

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

The dominant error is:

open-in-target not supported in extension

In one session, this was logged 18536 times, with peaks around 805 occurrences per second.

What steps can reproduce the bug?

Open the Codex VS Code extension.
Start any task that causes Codex to edit files locally.
A simple repro prompt is:

Rename this function across the project, update imports/usages, and apply the edits directly.

Make sure the change affects multiple files so the thread/diff UI renders several file diffs.
Wait for Codex to stream the edits and render the diff view in the thread.
Observe:
- CPU usage rises sharply
- the machine heats up
- extension host logs start spamming open-in-target not supported in extension

This is easier to reproduce with multi-file edits than with a single-file change.

What is the expected behavior?

Rendering diffs after Codex edits files should not trigger unsupported API calls in VS Code extension mode.

Expected behavior:

the diff UI should render normally without CPU spikes
the extension should not call Electron-only or unsupported APIs in extension mode
unsupported optional features should gracefully no-op instead of generating error/log storms

Additional information

Environment:

macOS
VS Code extension webview
Extension version: openai.chatgpt-26.325.31654-darwin-arm64

I inspected the shipped source maps locally and found what looks like the main cause:

CodeDiff ends up querying open-in-targets
this still happens in extension mode
but the extension host explicitly throws for that API:
- open-in-target not supported in extension

I also tested a local hotfix in the installed bundle that gated this query to Electron-only behavior:

queryFn:async()=>document.documentElement.dataset.codexWindowType==="electron"
  ? Je(`open-in-targets`,{params:{cwd:e}})
  : {preferredTarget:null,targets:[],availableTargets:[]}

After that change, the main log storm stopped and the heating issue was greatly reduced. That suggests the bug is likely caused by CodeDiff querying open-in-targets even when running inside the VS Code extension host, where that API is unsupported.

There also appears to be a smaller secondary issue where local-environments is queried in extension mode, but open-in-targets is by far the dominant failure path.

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

VSCode extension: open-in-targets error loop causes high CPU (Code Helper Renderer 100%+) #16849
High CPU usage triggered by rendering file/code links in chat; confirmed open-in-target failure loop in extension #16320
VS Code extension spams unsupported requests / thread-stream-state-changed broadcasts, causing high CPU/GPU usage on macOS #15397
[Codex Extension][VS Code][macOS] Renderer CPU spikes after file-changing task completes #15958
high CPU consuming when codex diff render #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

@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 #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

+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

cek #16849

@shx2005

@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:

I patched out the original thread-stream-state-changed / local-environments failure paths.
After restart, those exact signatures dropped to zero.
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 #15330 (comment)

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: #16850 (comment)

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.

Navigation Menu

Repository navigation

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

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

具体修复思路

具体修复思路

Repro environment

Observed

Fix verified

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Apr 5, 2026

MingLi3306 commented on Apr 5, 2026

shx2005 commented on Apr 5, 2026

具体修复思路

ofrnsb commented on Apr 5, 2026

MingLi3306 commented on Apr 6, 2026

具体修复思路

abhii-roy commented on Apr 7, 2026

ofrnsb commented on Apr 8, 2026

jlenoble commented on Apr 11, 2026

jlenoble commented on Apr 11, 2026

arieverhoeven commented on Apr 13, 2026

bhack commented on Apr 15, 2026

darcywudc commented on Apr 15, 2026

Repro environment

Observed

Fix verified

SunshineU commented on Apr 16, 2026

nicohouillon commented on Apr 22, 2026

arieverhoeven commented on May 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions