VSCode extension: open-in-targets error loop causes high CPU (Code Helper Renderer 100%+)
Summary
The openai.chatgpt VS Code extension (Codex) has a bug where the open-in-targets and set-preferred-app handlers throw an error instead of returning gracefully. Because the webview queries open-in-targets on a 1-minute interval (staleTime: ONE_MINUTE), the failure triggers a React Query retry loop, resulting in continuous log spam and sustained 100-170% CPU usage on Code Helper (Renderer) processes.
This happens in every open VS Code window that has the Codex panel loaded.
Affected versions
26.325.31654-darwin-arm6426.5401.11717(latest as of 2026-04-05)
Evidence
VS Code extension logs rotate 6+ times within a single session:
~/.vscode/Code/logs/.../exthost/openai.chatgpt/Codex.1.log (1,556 lines)
~/.vscode/Code/logs/.../exthost/openai.chatgpt/Codex.2.log (1,556 lines)
~/.vscode/Code/logs/.../exthost/openai.chatgpt/Codex.3.log (1,556 lines)
~/.vscode/Code/logs/.../exthost/openai.chatgpt/Codex.4.log (1,556 lines)
~/.vscode/Code/logs/.../exthost/openai.chatgpt/Codex.5.log (1,556 lines)
~/.vscode/Code/logs/.../exthost/openai.chatgpt/Codex.6.log (1,556 lines)
Repeated error:
Error: open-in-target not supported in extension
at open-in-targets (extension.js:255:22561)
at W_.handleVSCodeRequest (extension.js:255:27618)
at Qw.fetch (extension.js:214:1973)
...
Activity Monitor during the loop:
Code Helper (Renderer) 171.1% CPU
Code Helper (Renderer) 112.4% CPU
Code Helper (Plugin) 31.6% CPU
Root cause
In extension.js, both handlers are intentional stubs for features unsupported in extension mode, but they throw instead of returning gracefully:
// extension.js (both 26.325.31654 and 26.5401.11717)
"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")
},
The webview (index-*.js) queries open-in-targets via React Query with staleTime: ONE_MINUTE:
queryFn: async () => pr(`open-in-targets`, { params: { cwd: e } }),
queryKey: Sr(`open-in-targets`, { cwd: e }),
staleTime: Fr.ONE_MINUTE
When the query throws, React Query retries, creating a continuous failure loop.
Requested fix
Return an empty/no-op response instead of throwing, so the webview treats the feature as unavailable without retrying:
"open-in-targets": async () => ({ targets: [] }),
"set-preferred-app": async () => ({}),
This makes the behavior consistent with other unsupported stubs in the extension and stops the retry loop entirely. The fix is a one-liner in the extension source, no functional change, just converting an unhandled throw into a graceful empty response.
Showing cached comments. Read the full discussion on GitHub ↗
33 Comments
cc @bolinfest @jif-oai @aibrahim-oai @nornagon-openai @dylan-hurd-oai @charley-oai — tagging core contributors, this affects the VS Code extension specifically.
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
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.
run this script to fix it
Thanks a lot to identifying and solving the problem. After using the script, the behavior of the CPU over usage seems disappear.
Moreover, thanks to @bagerxx for leading me to see this solution.
Thanks a lot, this patch really works on M1 Max macOS 2.6.
Thank you for your help.
Thank you for your help.
Thanks for the investigation.
I applied the workaround locally on macOS by changing:
"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")},to:
"open-in-targets":async()=>({targets:[]}),"set-preferred-app":async()=>({}),After restarting VS Code, Codex loaded normally and the high CPU / overheating issue disappeared.
Really appreciate you sharing this.
Great find, I had to kill VSCode after every prompt in the Codex plugin because of the 100% CPU
Little script i made that fixes it since any manual fixes break on update:
Can we get an official fix please Codex team?
lets hope so lol
I dug into this on macOS and can confirm the same failure mode with process samples and extension logs.
Environment:
1.114.026.4 (25E246)openai.chatgpt-26.325.31654-darwin-arm64What I observed:
Codex.logandcodex-ipcopen under theopenai.chatgptVS Code log directorysampleof the extension-host process showed heavy time inspdlog.nodeflushing / rotating log files, consistent with a log stormsampleoutput for the renderer processes showed hot Electron/V8 main-thread work rather than idle waiting, which lines up with a busy webview/render loop on top of the extension-host loggingLog-storm evidence:
Codex.1.logthroughCodex.6.log, each around5.24 MBCodex.logwas still being appended while I checked itCodex.log, I counted583occurrences ofopen-in-target not supported in extensionin a0.777swindowSo from this machine at least, the pattern is:
open-in-targetsrequests start failing in a tight loopThis lines up with the root-cause analysis in the issue body: the unsupported handler is throwing instead of returning a graceful no-op, and the repeated failures drive both log churn and renderer churn.
Additional confirmation: VSCodium on Linux, with timing analysis
Environment:
26.406.31014---
Key observation
This is not a slow polling issue. The errors fire in a tight burst loop — 11 errors within ~209ms, with no backoff whatsoever.
Timing breakdown from log:
| Gap | Interval |
|-----|----------|
| 17:54:23.714 → .742 | +28ms |
| 17:54:23.742 → .765 | +23ms |
| 17:54:23.765 → .772 | +7ms ← tight pair |
| 17:54:23.772 → .799 | +27ms |
| 17:54:23.799 → .822 | +23ms |
| 17:54:23.822 → .829 | +7ms ← tight pair |
| 17:54:23.829 → .854 | +25ms |
| 17:54:23.854 → .886 | +32ms |
| 17:54:23.886 → .917 | +31ms |
| 17:54:23.917 → .923 | +6ms ← tight pair |
Errors appear in pairs separated by ~6–7ms, with ~23–30ms between groups. This suggests multiple parallel call sites firing simultaneously (e.g. a render cycle or event fan-out), not a simple retry timer.
---
Observed behavior
Failing endpoint
vscode://codex/open-in-targets
The handler throws instead of returning gracefully, and the caller retries with no backoff — confirmed by the tight burst pattern above.
---
Confirmed fix works: manually patching open-in-targets to return { targets: [] } instead of throwing eliminates the CPU spike and log spam entirely. Tested on VSCodium Linux x64, extension 26.406.31014.
Patch confirmed working — no more
open-in-targetserrors or CPU spike after reload.---
Separately, while testing I noticed a different warning flooding the log during
normal text rendering (no tools/diffs involved):
[IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed
This appears to be an independent bug — it reproduces without the
open-in-targetsissue and vice versa. Causes ~5 MiB/s of disk writes during streaming responses.
Not filing here — just flagging in case it's already tracked.
I could reproduce this on Windows as well, and the same workaround fixes it there.
For anyone who needs a temporary Windows-side patch before an official fix lands, this PowerShell script backs up
extension.js, replaces the two throwing handlers with no-op return values, and verifies the result.For Antigravity, use:
$env:USERPROFILE\.antigravity\extensions\openai.chatgpt-*\out\extension.jsFor VS Code, change that path to:
$env:USERPROFILE\.vscode\extensions\openai.chatgpt-*\out\extension.jsBug still in the new 26.409.20454 release that overwrote my previous fixed extension.js
Hi all! We have merged a fix and this should be addressed by the next release. Sorry about the close notification - linear was too eager at closing the ticket when we mark the task done internally.
thanks @shijie-oai!
you might want to see another cases as well, will describe it here later.
Hi, thanks for the update.
Do you have an estimated timeline for when the next release will be rolled out? The current issue is blocking us from using the feature, so it’s quite urgent on our side.
Appreciate your help!
Hello everyone!! Will running the fix script affect the extension's functionality in the future? What happens to the changes after the update? Will I need to do anything to undo all the changes made by the script?
Or does anyone have information on how often they release?)
Thank you for sharing, investigating, and resolving this issue.
Hi all! We should be releasing a VSCE version soon - I will post back when the version is updated.
The latest update made it even worse 😭
(93 °C – average core temperature . Its 199 °F)
Are there any ways to help troubleshoot this? I can share system logs or something
<img width="941" height="373" alt="Image" src="https://github.com/user-attachments/assets/c201b2ab-73b0-4f72-bbad-c324101b0941" />
<img width="517" height="237" alt="Image" src="https://github.com/user-attachments/assets/33b5dc09-27d9-465a-8abb-9eb61075320c" />
i will maintain it and publish a GitHub repo so people can clone and run it instead of waiting on OpenAI to fix it.
this script still works.
Does it work or not?
Does the newest version 26.415.20818 solved this issue? Same problem happened when I using the codex extention.
hmmm, it does work on my machine
update to 26.5409.20454 using VSIX then run that script. works perfectly
26.5415.20818 is the newest version, and it seems like remove the parameter used in the script, which cause the failure of it.
<img width="1187" height="400" alt="Image" src="https://github.com/user-attachments/assets/0cc906e2-9a15-408c-b1f4-bdba8e2f8dd5" />
My cpu was about 130% with 417 (or 5417 pre release) , I tried the patch but didnt work :
Then I downgraded to .409. and applied the patch, but perf got even worse (300%)
The script doesnt fix the problem unfortunately
+1
that's the pain-point with personal patch, it only works on specific circumstance, in this case, mine.