Performance: high CPU utilization with IDE extension
What version of the IDE extension are you using?
VS Code extension openai.chatgpt 26.318.11754 (linux-x64)
What subscription do you have?
ChatGPT Pro
Which IDE are you using?
Codex in VS Code chat
What platform is your computer?
Linux x64 Code - OSS 1.112.0 stable
What issue are you seeing?
While using the Codex VS Code extension on Linux, one or more Electron processes (electron --type=zygote) go to very high CPU.
The strongest signal is this:
if I disable the openai.chatgpt extension, the hot Electron processes immediately stop / exit.
So the CPU runaway appears to be caused by the extension or by the extension-host / Electron interaction, not by project code.
I initially suspected a local sandbox wrapper, but I was later able to reproduce the same problem outside that wrapper on the same repository. So the sandbox does not appear to be required to trigger the bug.
What steps can reproduce the bug?
- Open a Linux workspace in Code - OSS.
- Use Codex chat for a few iterations.
- Observe one or more Electron
--type=zygoteprocesses going hot. - Disable the
openai.chatgptextension. - The hot Electron processes immediately stop.
This reproduces reliably for me on at least one medium/large repository.
What is the expected behavior?
If a feature is unsupported or a request fails, the extension should degrade gracefully and should not trigger a sustained high-CPU loop in Electron.
Additional information
Relevant observations:
- Hot processes are Electron zygote processes.
- The main thread of the hot process is the one burning CPU.
- Disabling only
openai.chatgptimmediately makes the hot processes go away.
I tested both without and with:
--enable-proposed-api openai.chatgpt
Results:
- Without
--enable-proposed-api openai.chatgpt
- renderer logs contain errors such as:
CANNOT USE these API proposals 'chatSessionsProvider, languageModelProxy'chatSessions/newSession is a proposed menu identifier
- With
--enable-proposed-api openai.chatgpt
- those renderer errors disappear
- normal registration appears instead
- but the high CPU issue still reproduces
So enabling proposed APIs changes renderer behavior, but does not fix the main CPU runaway.
The log pattern that remains during the hot state is a very large flood of:
open-in-target not supported in extension
and also:
Received broadcast but no handler is configured method=thread-stream-state-changed
Representative stack path from the logs points into the extension and VS Code extension host IPC:
open-in-targets (...) /out/extension.jshandleVSCodeRequest (...)extensionHostProcess.jsMessagePortMain
In one run, the Codex*.log files for the affected window contained roughly 13k repeated matches for this error family.
Most important final confirmation:
disabling only the openai.chatgpt extension immediately made the hot Electron processes go away.
Related issues that seem adjacent but not identical:
- #3022
- #6835
- #7150
- #7487
I can provide renderer/exthost/Codex logs if needed.
What steps can reproduce the bug?
I could not reduce this to a deterministic minimal sequence of clicks, but I can reproduce it with this workflow:
- Open a medium/large repository in Code - OSS on Linux.
- Start a Codex chat in the VS Code extension.
- Interact with the chat for a few turns.
- Let Codex make its first file modifications in the repository.
- After that point, it's very likely to have one Electron
--type=zygoteprocesses may get stuck at very high CPU usage and remain there.
For me, the problem tends to appear after the first successful file edit performed through Codex, never immediately at chat startup.
A strong confirmation step is:
- Disable the
openai.chatgptextension. - The hot Electron processes stop immediately.
What is the expected behavior?
_No response_
Additional information
_No response_
26 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
also on macos
I had the same problem.
In my case, VS Code’s extension host eventually crashed and restarted. The crash artifacts point to a Node/V8 heap OOM (
JavaScript heap out of memory/Ineffective mark-compacts near heap limit).What I found locally:
vscode://codex/open-in-targetsopen-in-target not supported in extensionThis looks related to #15397 too. That one seems to describe the same underlying issue from another angle.
Exactly the same issue. MacBook Activity Monitor shows one or two Code Helper Renderer spiking 80-200% CPU usage whenever the chat moves and renders. It gets several of this per sec in the logs:
[warning] [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed.Not sure if it is a workaround. It seems to be a VS Code extension main problem. Using the Codex app with popup as side panel works effectively the same while the Codex Renderer seems to be quite normal sub 40% CPU usage.
same as me
<img width="548" height="338" alt="Image" src="https://github.com/user-attachments/assets/a40d9db7-5780-4e35-a0de-e64791e8f94f" />
Same issue here, one prompt to the codex agent on Ubuntu 24.04 through VS Code and my fans spin up and won't stop until I kill the extension. Happens every single time.
... and quick update. I rolled back to 0.4.69 and I haven't had a single problem since with the high cpu usage. Seems like something after that caused it.
I have the same problem. I rolled back to 26.5313.41514, that version still works fine.
CPU usage also goes down again, when i click "new chat" in the extension. But when i switch back to the old one, one core goes back up to 100%. It's also the --type=zygote process for me.
Codex extension logs spam that error here:
Same problem still present in latest version, still not fixed, after so many weeks.
I have the same problem, which version is the best now and doesn't have this bug?
I just let codex fix the issue in the bundle, here is what it did. After that, CPU usage is back to normal.
Environment
---
Summary
During any streaming response (even a single short sentence, no tools, no diffs, no agent mode), the extension continuously emits:
at ~30–35 events per second.
This results in ~5 Mbit/s sustained log writes for the entire duration of the stream.
This issue is independent from
open-in-targetsfailures (#16849).That handler has been locally patched (
async () => ({ targets: [] })) and those errors are fully resolved.The warning flood persists unchanged.
Additionally, the workaround mentioned in other comments:
does NOT resolve this issue in this environment.
---
Steps to reproduce
openai.chatgptextension enabled"Hello")``
text
``openai.chatgpt/Codex.log
---
Key observations
Important nuance (stream phases):
This strongly suggests the issue is tied specifically to the response rendering / streaming phase, not earlier agent or reasoning stages.
---
Log sample
From a real session (2026-04-09 18:57):
Observed intervals: ~25–40 ms
→ ~30–35 events/sec
---
Impact
---
Related issues
---
Hypothesis
Looks like
thread-stream-state-changedevents are emitted during the render phase without a registered consumer in this environment.I have a similar problem. After a few back-and-forth prompts in the same conversation, the OpenAI ChatGPT/Codex VS Code extension starts using high CPU continuously.
CPU usage does not return to idle after the response is complete. VS Code keeps the machine hot and the fan running continuously until I fully close and reopen VS Code.
Steps to reproduce:
Expected behavior:
CPU usage may spike while processing a prompt, but it should return to normal idle levels after the response is complete.
Actual behavior:
After a few prompts in the same conversation, CPU usage remains elevated indefinitely. The machine heats up and the fan keeps running until VS Code is fully closed and reopened.
Environment:
Workaround for log spam (Linux, extension.js patch)
For anyone who just wants to silence the warning flood without waiting for an official fix — the warning is emitted in
IpcClient.handleBroadcastwhenbroadcastHandlershas no entry for the method andanyBroadcastHandlersis empty. A minimal patch adds a method-name guard before thelogger.warningcall:Adjust the extension version in the path to match your install. The patch survives until the extension auto-updates.
Note: this only silences the log spam — the broadcast is still unhandled, so it doesn't fix any underlying streaming/UI issue. It does stop the high-frequency disk writes caused by the log rotation.
Separate issue: even with the warning suppressed, the extension continues writing ~5 MiB/s to disk during model streaming responses. That is a different bug: #17320
Thanks to JohnnyBill and piotrkacala for the temporary workarounds.
I tested JohnnyBill’s patch that changes the
open-in-targets/set-preferred-apphandlers so they return an unsupported result instead of throwing, and I also tested piotrkacala’s patch that suppresses thethread-stream-state-changedwarning flood.On my side, using both together helps a lot and clearly reduces the severity of the problem, but it still does not fully resolve it.
So these are useful temporary mitigations...
For reference, anyone trying them should make sure to back up
extension.jsfirst and run the patch commands from the directory where that file is located.JohnnyBill patch:
piotrkacala patch:
Hi all! Thanks for all the information on investigation! I have a fix out for
open-in-targets(related to https://github.com/openai/codex/issues/16849). Sorry about the delay here and we should have a vsce release this week to address that issue. I will also put up fixes for the other internal to make sure we can address all those performance issue. Again really appreciate all the feedback here!Yup. Same issue here. That's how I found this thread. Using the codex extension
26.417.40842and my laptop gets HOT.This is ridiculous.
Same on Windows 10 and latest VSCodium. Extension starts to consume CPU after 26.5401.11717.
PS freshly installed 26.5417.40842 seems does not fix this problem
The version just before 26.417.40842 had fixed the issue, but since the 26.417.40842 update, the CPU problem has returned and seems even worse than before.
The CPU usage spikes as soon as the extension is opened, without even needing to send a prompt.
On my side, I’m using the extension in VSCode on Ubuntu Linux.
With codex I confirm this is still reproducible as of April 24, 2026 on Windows with VS Code and the Codex extension 26.5422.21459. In my case, this does not look like the old
open-in-targets/set-preferred-appthrow loop anymore, because the current extension build appears to stub those calls instead of throwing.However, high CPU is still happening due to a different event/retry storm. My
Codex.logshows massive repetition ofworker_rpc_response_error error={} method=stable-metadata workerId=gitplus continuous[IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changedwarnings. In one session I saw ~33kstable-metadataerrors and 400+ unhandledthread-stream-state-changedbroadcasts. I also confirmed thatcodex.exe app-server --analytics-default-enableditself becomes a CPU hotspot, so this is not just a renderer/UI issue. I locally reduced the problem by patching the extension to stop retrying failedstable-metadatarequests, suppress the unhandledthread-stream-state-changed/query-cache-invalidatewarning spam, and remove the persisted-state startup gate. That strongly suggests the current regression is caused by repeated Git metadata failures plus broadcast/log churn, not by a one-off machine-specific problem.Seriously this is very concerning. Every time I leave codex on idle the CPU usage goes very high and my laptop fans are on max speed. This is not acceptable for product that runs on paid service.
I have to exit VS code to stop this nonsense.
Codex VS Code extension is spamming Output panel with hundreds or thounsands of warning messages per second, new message every few microseconds. The number of warnings is too high, not throttled and possibly causing high CPU usage:
This is just small example of logs:
...
2026-04-27 10:09:46.637 [warning] worker_rpc_response_error error={} method=stable-metadata workerId=git
2026-04-27 10:09:46.646 [warning] worker_rpc_response_error error={} method=stable-metadata workerId=git
2026-04-27 10:09:46.651 [warning] worker_rpc_response_error error={} method=stable-metadata workerId=git
2026-04-27 10:09:46.661 [warning] worker_rpc_response_error error={} method=stable-metadata workerId=git
2026-04-27 10:09:46.667 [warning] worker_rpc_response_error error={} method=stable-metadata workerId=git
2026-04-27 10:09:46.674 [warning] worker_rpc_response_error error={} method=stable-metadata workerId=git
2026-04-27 10:09:46.682 [warning] worker_rpc_response_error error={} method=stable-metadata workerId=git
2026-04-27 10:09:46.689 [warning] worker_rpc_response_error error={} method=stable-metadata workerId=git
2026-04-27 10:09:46.691 [warning] worker_rpc_response_error error={} method=stable-metadata workerId=git
2026-04-27 10:09:46.702 [warning] worker_rpc_response_error error={} method=stable-metadata workerId=git
2026-04-27 10:09:46.709 [warning] worker_rpc_response_error error={} method=stable-metadata workerId=git
...
environment:
Fedora 42
VS Code 1.117.0
tested Codex versions: 26.422.30944, 26.5422.30944 (Pre-release)
Proposed fix: throttle the logs to be issued once in a second instead of microseconds
Ref issue: https://github.com/openai/codex/issues/18515
This is still ongoing, had to force-shutdown my laptop multiple times yesterday until I found this thread. I am on
26.429.30905.Update: This is not just VSCode extension related (thought it was) - opening the Codex app does the same thing (only when VSCode is opened as well though)
I’m seeing what looks like the same issue on Linux with a newer extension build, sharing only the deltas in case they help.
Environment:
What I’m seeing:
codex app-serverplus MCP helpers (chrome-devtools,tavily,context7) active underneath itthread-stream-state-changedandunsupported feature enablement auth_elicitationAdditional note:
ENOSPCwatcher failures were addressed by increasingfs.inotify.max_user_watchesto 524288Happy to provide a trimmed log snippet if that would be useful.
Still having this issue too