High CPU usage on macOS after updating Codex in VS Code extension to 26.325.31654

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

• #16210
• #16108
• #15764
• #15706
• #15958

Powered by Codex Action

+1

Yeah I've been experiencing this several times. I've had this M4 over a year and I've only just started hearing the thermal fans after this bug has started cropping up. Not sure what I can say thats technical.

+1

I can confirm this on the same extension version (26.325.31654) and on macOS 26.4.

In my case the hot process is mainly the VS Code extension host, not the Codex backend:

• Code Helper (Plugin): about 36.4% CPU
• codex app-server: about 2.1% CPU

I also see repeated warnings in the Codex logs:

[warning] [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed

Examples from one affected run:

• Codex.log:12
• Codex.1.log:1461
• Codex.3.log:255
• Codex.3.log:256
• Codex.3.log:265

The affected session also rotated logs quickly:

• Codex.1.log through Codex.6.log: 5.0 MB each
• Codex.log: 2.5 MB

This makes my case look very close to both:

• #15397 for the exact thread-stream-state-changed warning loop
• this issue (#16231) for the regression on 26.325.31654

I am seeing a consistent high-CPU loop in the Codex VS Code extension that appears to be tied to a single conversation state, not prompt complexity.

Environment

• VS Code: 1.112.0
• Commit: 07ff9d6178ede9a1bd12ad3399074d726ebe6e43
• Electron: 39.8.0
• Chromium: 142.0.7444.265
• Node.js: 22.22.0
• V8: 14.2.231.22-electron.0
• OS: Fedora 43, Linux x64, kernel 6.19.10-200.fc43.x86_64
• Codex extension:
• Identifier: openai.chatgpt
• Version: 26.325.31654 (linux-x64)

Symptoms

• After several back-and-forth prompts in one Codex conversation, extension host CPU and renderer CPU ramp up and remain high.
• This is independent of prompt complexity (also happens with trivial prompts).
• Closing only that conversation immediately drops CPU back to normal.
• Starting a fresh conversation is fine initially, then the same high-CPU state returns after a few messages.
• The behavior is deterministic and reproducible.

Strong log signal

Logs show a tight repeated error loop:

• Error fetching: open-in-target not supported in extension
• URL involved: vscode://codex/open-in-targets
• Stack repeatedly includes extension request handling and then VS Code extension host message delivery pipeline.

In my case, this repeats at very high frequency (roughly dozens of log entries per second), and accumulates into many thousands of repeated entries across rotated logs in one session. That strongly suggests an immediate retry loop with no effective backoff once this state is reached.

Why this looks like an extension-side conversation-state loop

• The error indicates a capability mismatch: a request path is being issued that the installed extension build reports as unsupported.
• The loop is tied to a conversation lifecycle (close conversation, CPU drops immediately; reopen/start new, eventually re-enters loop).
• This does not look model-side or prompt-content-side; it looks like a per-conversation UI/extension state machine repeatedly issuing an unsupported action.

Repro steps

1. Open VS Code on Fedora 43 with extension version 26.325.31654 enabled.
2. Start a new Codex conversation.
3. Exchange 3-5 prompts/replies (content does not matter).
4. Observe extension host and/or renderer CPU rise and stay high.
5. Close that conversation (or panel): CPU drops quickly.
6. Start another conversation and repeat: same pattern.

The problem happens in two different Fedora 43 computers (so it's not tied to one environment).

Current workarounds

• Keep conversations short; close and restart when CPU climbs.
• Reset Codex NUX state from Command Palette, then reload window (sometimes helps clear stuck state).
• If available, install an older extension version (for example a Feb 2026 build) and disable auto-update for this extension as a temporary mitigation.

Regression check

• I reverted to Codex extension version 0.4.79, and this high-CPU loop does not occur with that version in the same environment.

Can confirm that the issue disappears when reverting to 0.4.79. In my case using the Codex extension in Antigravity 1.21.9 (antigravity helper processes CPU usage to 100-200% until ending conversation.

yes its happening after 2 o 3 prompts, as soon as the codex panel its closed it goes back to normal even tho the agent it still running in the background

+1, macbook is roasting my hands in VSCode with Codex, high CPU usage every time

I encountered the same issue; the temperature only slowly returned to normal after I closed the chat panel.

Rolling back to 0.4.79 can solve this. Didn't try later versions

This is a continuation to my previous comment. This time, I am providing a workaround that I have tested in my environment. Please pardon if this is not the correct posting format for this forum.

Codex VS Code Extension Bug and Workaround

Summary

This document describes a reproducible bug in the Codex VS Code extension and a local workaround that avoids the resulting log flood and high CPU usage.

Affected build observed locally:

• openai.chatgpt-26.325.31654-linux-x64

Important scope note:

• this workaround has only been tested on one specific Linux computer
• it has not been validated across multiple machines or operating systems
• results on other systems may differ

Tested Environment

This workaround was verified only in the following environment:

• operating system: Linux 6.19.10-200.fc43.x86_64 x86_64 GNU/Linux
• VS Code: 1.112.0
• VS Code architecture: x64
• Codex extension: Codex – OpenAI's coding agent
• extension version: 26.325.31654

No claim is being made here that the workaround is universally safe or portable. It is simply the environment where it was observed and tested.

Observed symptoms:

• repeated extension host errors
• very noisy Codex logs
• high CPU usage
• Codex diff/open flow triggering the problem

The root issue appears to be that the renderer/webview calls internal routes that the extension host in the same build does not support, and the host throws hard errors instead of degrading safely.

Bug Details

The failing internal routes observed locally were:

• vscode://codex/open-in-targets
• vscode://codex/local-environments

The corresponding extension host errors were:

• open-in-target not supported in extension
• local-environments is not supported in the extension

This makes the issue look like an extension regression or feature mismatch inside the shipped build, not a repo-specific bug.

Reproduction

1. Open a repository in VS Code.
2. Make a tiny file change so there is a diff.
3. Trigger the Codex diff/open flow.
4. Watch the Codex extension log.

Example Log Sample

Representative errors seen in the Codex log:

2026-04-05 13:56:47.xxx [error] Error fetching errorMessage="open-in-target not supported in extension" url=vscode://codex/open-in-targets
2026-04-05 14:01:44.662 [error] Error fetching errorMessage="local-environments is not supported in the extension" url=vscode://codex/local-environments

Representative warning that remained even after the workaround:

2026-04-05 14:04:27.xxx [warning] [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed

Useful example log paths from the investigation:

• Linux example: ~/.config/Code/logs/<session>/window1/exthost/openai.chatgpt/Codex.log
• macOS example: ~/Library/Application Support/Code/logs/<session>/window1/exthost/openai.chatgpt/Codex.log
• Windows example: %APPDATA%\\Code\\logs\\<session>\\window1\\exthost\\openai.chatgpt\\Codex.log

Why This Looks Like an Extension Bug

• The issue was reproduced with a normal repo diff.
• The extension host code explicitly threw for internal routes used by the UI.
• After replacing those throws with safe fallback responses, the error flood stopped.
• The repo itself was only a trigger, not the cause.

So the best diagnosis is:

• the extension renderer requests unsupported features
• the extension host throws instead of failing gracefully

Workaround

The workaround is to patch the installed extension host so unsupported handlers return safe fallback responses instead of throwing.

This disables the affected unsupported features cleanly instead of letting them enter an error loop.

What The Workaround Changes

The patched handlers do this:

• open-in-targets returns no available targets
• set-preferred-app returns success: false
• local-environments returns an empty list
• local-environment-config returns exists: false
• local-environment-config-save returns success: false

Tradeoffs

These specific features will not work in the patched build:

• Codex open-target preference selection
• Codex local-environments settings/config flow

What should still work:

• normal Codex chat/task flows
• Codex diff viewing
• general extension usage without the log flood

File To Patch

Installed extension file:

• Linux: ~/.vscode/extensions/openai.chatgpt-26.325.31654-linux-x64/out/extension.js
• macOS: ~/.vscode/extensions/openai.chatgpt-26.325.31654-darwin-<arch>/out/extension.js
• Windows: %USERPROFILE%\\.vscode\\extensions\\openai.chatgpt-26.325.31654-win32-<arch>\\out\\extension.js

Notes:

• The exact folder name may vary by extension version and platform.
• On macOS, <arch> is usually arm64 on Apple Silicon or x64 on Intel.
• On Windows, <arch> is commonly x64.
• If the exact folder name is different, open your VS Code extensions directory and look for the installed openai.chatgpt-* folder.

Patch

--- a/out/extension.js
+++ b/out/extension.js
@@
-"local-environment":async()=>{throw new Error("local-environment is not supported in the extension")},
-"local-environments":async()=>{throw new Error("local-environments is not supported in the extension")},
-"local-environment-config":async()=>{throw new Error("local-environment-config is not supported in the extension")},
-"local-environment-config-save":async()=>{throw new Error("local-environment-config-save is not supported in the extension")},
+"local-environment":async()=>({environment:{type:"error",error:{message:"Local environments are not available in the extension."}}}),
+"local-environments":async()=>({environments:[]}),
+"local-environment-config":async({configPath:e})=>({configPath:e,exists:!1,raw:null}),
+"local-environment-config-save":async({configPath:e})=>({configPath:e,success:!1}),
@@
-"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")},
+"open-in-targets":async()=>({preferredTarget:null,availableTargets:[],targets:[]}),
+"set-preferred-app":async()=>({success:!1}),

Install Instructions

1. Find your installed Codex extension folder.

Examples:

• Linux: ~/.vscode/extensions/
• macOS: ~/.vscode/extensions/
• Windows: %USERPROFILE%\\.vscode\\extensions\\

Inside that directory, locate the installed openai.chatgpt-* folder for your current build and then open its out/extension.js.

1. Back up the original file:

cp ~/.vscode/extensions/<openai.chatgpt-folder>/out/extension.js \
   ~/.vscode/extensions/<openai.chatgpt-folder>/out/extension.js.bak

On macOS, use the same command in Terminal:

cp ~/.vscode/extensions/<openai.chatgpt-folder>/out/extension.js \
   ~/.vscode/extensions/<openai.chatgpt-folder>/out/extension.js.bak

1. Open the installed extension file:

~/.vscode/extensions/<openai.chatgpt-folder>/out/extension.js

On macOS, this is the same default location. The main difference is just the platform-specific folder name, for example:

~/.vscode/extensions/openai.chatgpt-26.325.31654-darwin-arm64/out/extension.js

1. Replace the original handler blocks with the patched versions shown above.

1. Reload VS Code:

• open the command palette
• run Developer: Reload Window

1. Re-test the same Codex diff/open flow and inspect the newest Codex log if needed.

macOS Notes

This workaround has not been tested on macOS in this investigation.

Based on the extension layout, it should be similar on macOS as long as you patch the installed extension.js for the macOS build of the extension, but that is an informed expectation rather than a verified result.

What likely changes on macOS:

• the extension folder name will typically contain darwin
• the architecture is usually arm64 on Apple Silicon or x64 on Intel
• the VS Code log location is under ~/Library/Application Support/Code/logs/

What likely does not change:

• the workaround logic
• the patch contents
• the need to reload VS Code after editing the file

Remove Instructions

Restore the backup:

cp ~/.vscode/extensions/<openai.chatgpt-folder>/out/extension.js.bak \
   ~/.vscode/extensions/<openai.chatgpt-folder>/out/extension.js

Then reload VS Code again.

You can also remove the workaround by reinstalling or updating the extension, which usually overwrites the patched file.

Results Seen After Applying the Workaround

In the latest verified session:

• open-in-target not supported in extension: 0
• local-environments is not supported in the extension: 0
• Error fetching: 0
• no-client-found: 0

The remaining warnings were thread-stream-state-changed, but they did not appear to reintroduce the high CPU behavior.

Suggested Upstream Fix

The extension should return safe fallback responses for unsupported internal routes instead of throwing hard errors. It would also be worth auditing the renderer so the VS Code extension build does not request features that are unavailable in that host environment.

Created a universal patch script for Apple Silicon. (before patching close your vs-code)

What it does:

Finds all extension.js files matching openai.chatgpt-*-darwin-arm64 in:
~/.vscode/extensions
~/.vscode-insiders/extensions

Creates a backup: extension.js.bak.<timestamp>.

Applies 6 replacements regardless of the extension version number.

Verifies the patch was applied correctly and restores from backup if verification fails.

https://gist.github.com/GoXLd/cdbaa5598df152d1ef63feec4c50a717

Created a universal patch script for Apple Silicon. (before patching close your vs-code) What it does: Finds all extension.js files matching openai.chatgpt-*-darwin-arm64 in: ~/.vscode/extensions ~/.vscode-insiders/extensions Creates a backup: extension.js.bak.. Applies 6 replacements regardless of the extension version number. Verifies the patch was applied correctly and restores from backup if verification fails. patch-openai-chatgpt-extension-arm64.sh

is better this fix or just use older version of plugin?

is better this fix or just use older version of plugin?

It’s better to use the patch - it fixes a critical issue in the current version. Rolling back to an older version is only a temporary workaround and may lead to other bugs or missing updates.

On a MacBook Air M4, I switched to the pre-release version in the extension manager and disabled auto-update. It seems to have reduced the resource usage. I’ll continue monitoring the metrics.

<img width="717" height="765" alt="Image" src="https://github.com/user-attachments/assets/55e987cc-e87b-4324-a341-9d8d9442d8b7" />

When can we expect a stable fix for this. I am on a Macbook Pro M5 Pro 24GB Model. Although, I am not hitting my memory. But the Macbook gets very hot. It is reaching around 85-100 deg celcius. Switching to version 0.4.79 does limit the temperate to 61 dec C. However, we loose on the plan mode.

Does any one know any other fixes?

Created a universal patch script for Apple Silicon. (before patching close your vs-code)

Thanks! If you add:
"$HOME/.antigravity/extensions"
to the roots, it will also patch the extension when using this in Antigravity

> Created a universal patch script for Apple Silicon. (before patching close your vs-code) Thanks! If you add: "$HOME/.antigravity/extensions" to the roots, it will also patch the extension when using this in Antigravity

Done, patch updated https://gist.github.com/GoXLd/cdbaa5598df152d1ef63feec4c50a717

+++ support for both VS Code and VS Code Insiders arm64 extension paths;
Thanks for the feedback.

When can we expect a stable fix for this. I am on a Macbook Pro M5 Pro 24GB Model. Although, I am not hitting my memory. But the Macbook gets very hot. It is reaching around 85-100 deg celcius. Switching to version 0.4.79 does limit the temperate to 61 dec C. However, we loose on the plan mode. Does any one know any other fixes?

https://gist.github.com/GoXLd/cdbaa5598df152d1ef63feec4c50a717

It would be so nice to get this fixed, because now it feels like I have my old hot Intel Mac back

Hi all! sorry about the delay. I have a few ideas about the issue and will look into this now.

Just a note and some more evidence/logs below in case it helps.

Most importantly: I noticed the high cpu usage starts when a file is changed within the chat. it seems the issue relates to the file diff presentation.

I previously patched the installed extension host file (.../out/extension.js) so unsupported handlers returned safe responses instead of throwing. That workaround worked locally. After updating to a newer extension version, the issue returned because the extension update replaced the patched file.

Environment
OS: Linux fedora 6.19.11-200.fc43.x86_64 x86_64 GNU/Linux
VS Code: 1.112.0 (07ff9d6178ede9a1bd12ad3399074d726ebe6e43, x64)
Codex extension folders installed:
openai.chatgpt-26.325.31654-linux-x64
openai.chatgpt-26.409.20454-linux-x64 (current active build showing issue)

Repeated extension host errors for unsupported routes:
vscode://codex/open-in-targets
vscode://codex/local-environments
Very noisy warning stream (thread-stream-state-changed no-handler).
High CPU observed in VS Code/Codex processes during bursts.

Counts from today (just one chat session):
open-in-target not supported in extension => 939
local-environments is not supported in the extension => 2
thread-stream-state-changed warnings => 680
Burst density example:

open-in-target errors: 786 entries at 2026-04-11 08:40:53
open-in-target errors: 145 entries at 2026-04-11 08:40:54
thread-stream-state-changed: 54 entries at 08:44:28, 53 at 08:44:27

Representative log lines:
2026-04-11 08:40:52.991 [error] Error fetching errorMessage="open-in-target not supported in extension" ... url=vscode://codex/open-in-targets
2026-04-11 08:40:59.812 [error] Error fetching errorMessage="local-environments is not supported in the extension" ... url=vscode://codex/local-environments
2026-04-11 08:40:59.721 [warning] [IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed

Created a universal patch script for Apple Silicon. (before patching close your vs-code) What it does: Finds all extension.js files matching openai.chatgpt-*-darwin-arm64 in: ~/.vscode/extensions ~/.vscode-insiders/extensions Creates a backup: extension.js.bak.. Applies 6 replacements regardless of the extension version number. Verifies the patch was applied correctly and restores from backup if verification fails. https://gist.github.com/GoXLd/cdbaa5598df152d1ef63feec4c50a717

Your patch worked. Thank you.

Sorry people. I am still experiencing this. I just opened VS Code and I am not even using Codex, it is just displayed at the sidebar, and my MBA M4 got insanely hot and CPU usage is more than 100% in activity monitor. Version 26.409.20454:
I will try uninstalling it from VS Code and use it from the native app, I don't remember facing this issue when I used it with Codex app

<img width="962" height="633" alt="Image" src="https://github.com/user-attachments/assets/cf5e521d-1ef7-460e-8e2e-4a0a763653a3" />

From my experience, I think it's the problem of code diff? My codex remains normal when only asking it to give a structure of the code base.

Adding a Linux data point to this issue.

Symptom

Extension renderer (code --type=zygote) spins at 100-300%+ CPU while a
session is idle or stalled waiting for a permission prompt. Accumulated
CPU time grows very fast — one process hit 222 minutes of CPU time in
~2 hours wall-clock. Disabling Codex extension immediately returns the system to
idle.

Version range

Isolated to the Codex extension by version bisect:

• Buggy: 26.325.31654
• Last working: 26.325.21211

Rolling back to 26.325.21211 resolves the issue completely and
reproducibly.

Environment

• Ubuntu 24.04, kernel 6.17
• VS Code 1.115.0
• Confirmed on 3 machines in our team

Sorry people. I am still experiencing this. I just opened VS Code and I am not even using Codex, it is just displayed at the sidebar, and my MBA M4 got insanely hot and CPU usage is more than 100% in activity monitor. Version 26.409.20454: I will try uninstalling it from VS Code and use it from the native app, I don't remember facing this issue when I used it with Codex app

Try this patch https://gist.github.com/GoXLd/cdbaa5598df152d1ef63feec4c50a717

> Sorry people. I am still experiencing this. I just opened VS Code and I am not even using Codex, it is just displayed at the sidebar, and my MBA M4 got insanely hot and CPU usage is more than 100% in activity monitor. Version 26.409.20454: I will try uninstalling it from VS Code and use it from the native app, I don't remember facing this issue when I used it with Codex app Try this patch https://gist.github.com/GoXLd/cdbaa5598df152d1ef63feec4c50a717

I wonder what functions this patch actually disables ? I do really reply on codex to work on local projects.

> > Sorry people. I am still experiencing this. I just opened VS Code and I am not even using Codex, it is just displayed at the sidebar, and my MBA M4 got insanely hot and CPU usage is more than 100% in activity monitor. Version 26.409.20454: I will try uninstalling it from VS Code and use it from the native app, I don't remember facing this issue when I used it with Codex app > > > Try this patch https://gist.github.com/GoXLd/cdbaa5598df152d1ef63feec4c50a717 I wonder what functions this patch actually disables ? I do really reply on codex to work on local projects.

Read the thread above if you want the details - it stops what should be a harmless error logging situation for something that isn't supported from turning into an infinite loop and burning 100% of the cpu.

I’m currently avoiding updating, because I don’t want to risk running into the same bug.

Does anyone know if this has been officially fixed in newer versions?

Honestly, it’s still surprising that this bug made it into a release.

The biggest concern for me wasn’t even the heat - it was the battery drain and potential long-term degradation. That’s actually how I first noticed the issue: my battery dropped from 100% to 0% in about two hours on an M4. Only after that did I check Activity Monitor.

Guys, do you know any other ways beside downgrade to 0.4.79 version ?

Guys, do you know any other ways beside downgrade to 0.4.79 version ?

@Nikita-schetko
https://github.com/openai/codex/issues/16231#issuecomment-4205506808 (This patch script is for Apple Silicon (arm64) only)

@GoXLd

Does anyone know if this has been officially fixed in newer versions?

I’m on the latest stable (26.409.20454), and the high CPU load issue is still there unless you apply the patch from this thread

But, https://github.com/openai/codex/issues/16231#issuecomment-4227813993

@shijie-oai we need an update on this. This extension is not a hobby project; it is a product that enables us to use OpenAI's core agentic service for software development in VSCode + derivatives. That service is something we pay money for.
While there is a wonderful workaround provided in this thread by an enterprising user, that does not help the likely many thousands of users who have not stumbled upon this GitHub issue and are still struggling to understand why their IDE is running hot.

This is not a minor issue. 1) it is causing our computers to run hot, which makes fans run noisy, burns through battery cycles, and is incredibly eco-unfriendly; and 2) it is affecting ALL MAC USERS. That is a very large cohort that expects better than a meaningless apology after 2 weeks and then radio silence for another week with no meaningful updates. There are other options than OpenAI and this is the kind of thing that will repel your users. Do better. This should be an all-hands-on-deck moment for the Codex team.

issue is still present, codex is the only VSCode extension that i have installed. I have the latest VSCode and the latest Codex.

<img width="386" height="184" alt="Image" src="https://github.com/user-attachments/assets/319d9813-f4e5-4597-a3e9-0b084caeb914" />

This is still and issue in the latest extension update. I’ve been using the workaround from the comments above for about two weeks and haven’t noticed any side effects. In my case, it completely resolves the issue until the extension is updated and the workaround gets overwritten, at which point I need to apply it again.

Hi, @shijie-oai

I’d like to share a workaround and some findings regarding the high CPU usage and overheating issue on macOS (Apple Silicon) when using the ChatGPT/Codex VS Code extension.

After encountering the same problem described in OpenAI Codex issue #7972, I investigated further and noticed that the root cause appears to be related to the extension’s handling of local environment features (e.g. local-environment, local-environments, config handlers, etc.).

Key observations

• Rolling back to an earlier version temporarily resolves the problem (0.4.79).
• The problematic behavior seems tied to async handlers that continuously attempt to resolve local environment state.

Workaround / Patch

I created a patch script (macOS Apple Silicon only) that:

• Locates the installed extension bundle
• Replaces several async handlers with safe no-op implementations
• Prevents repeated background calls that appear to cause CPU spikes

Specifically, the script disables:
local-environment
local-environments
local-environment-config
local-environment-config-save
open-in-targets
set-preferred-app

After applying the patch: https://gist.github.com/GoXLd/cdbaa5598df152d1ef63feec4c50a717

• CPU usage returns to normal
• No overheating observed
• Extension remains usable for core features

Suggestion

It would be helpful to:

• Add _safeguards_ or throttling for these environment-related async calls
• Provide a setting to disable local environment integration
• Investigate potential infinite loops or excessive polling in these handlers

Thanks!

This problem still exists, I've completely re-install Vscode, and codex is the only plugin on my install, it still uses 100+ Cpu when codex panel is showing but nothing is going. I can say this problem exists since day one I use Codex in VSCODE. This is not a open source project maintained by volunteers, we paid thousands of dollars every month but they just cannot solve this for weeks.

<img width="495" height="166" alt="Image" src="https://github.com/user-attachments/assets/f8590dfd-b5f7-4204-b5d0-b41de30b625f" />

Facing the same issue on M4 Mac, CPU usage spikes to 200% due to Code Helper when Codex sidebar is open, but drops to normal when you close the sidebar (without reloading VS Code). However, it looks a person has found the issue and published a patch script on github for this issue - https://gist.github.com/almakompot/9796936f65cda204ad22c649f46483ea

We have pushed out a fix to address open-in-targets and set-preferred-app in v26.415.20818. I am currently following up address the local-environments.

We have pushed out a fix to address open-in-targets and set-preferred-app in v26.415.20818. I am currently following up address the local-environments.

So do we have an official fix to the heating issue?

local-environments fix will go out with our next vscode extension release and that should address the issues we are seeing here. Thanks for your patience!

Hi all! We have just released a new version of the extension - please let us know if you are still seeing any issue performance related. Thanks!

Hi all! We have just released a new version of the extension - please let us know if you are still seeing any issue performance related. Thanks!

Thanks for the update. I’m still seeing a performance issue on macOS (Apple Silicon)
26.422.20832

After the latest release, the extension can enter a tight loop and spam local API/IPC calls at ~400 requests/sec, which drives CPU usage and causes high temperatures.

As a temporary fix, I patched out/extension.js to short-circuit the local-environment related handlers (local-environment, local-environments, local-environment-config, local-environment-config-save, open-in-targets, set-preferred-app) with safe static responses, and simplified handleResolveStableMetadata to return stable cwd-based metadata only.

Result: request storm stops, CPU load drops, and temperature behavior is back to normal.

I already sent detailed reports with repro + security/perf impact.

On latest version, tried pre-release as well. Issue is not fixed on M4 Mac.

@GoXLd and @sachin-ag can you both /feedback and share the session ids with us? I am no longer seeing unhandled local-environments, open-in-targets, set-preferred-app issues on my end in the log.

@shijie-oai 019dbc4f-d9de-7162-b441-4a53405327f9

I am still facing the issue in the MacBook Pro M5 chipset laptop. Used the latest update available on the VS Code for codex extension.

bc833344-ebc1-4022-a219-2df227191a3f @shijie-oai same here m2 pro macbook running version: 26.5422.21459

The issue still persists even with the pre release version the CPU shoots upto 130% just by opening the codex chat which heats up the laptop as well happening on m5 pro

<img width="551" height="72" alt="Image" src="https://github.com/user-attachments/assets/c8fbfb9b-a16d-4389-b0b2-8b7a63d8c6fe" />

<img width="872" height="604" alt="Image" src="https://github.com/user-attachments/assets/a2a916cd-f766-4939-b4e7-b80cc680ba53" />

Follow-up: latest Codex extension still floods logs / high CPU

I am seeing a similar noisy-log/high-CPU issue again on a newer Codex VS Code extension build. I did not apply the local workaround before capturing this log.

Environment:

• Codex extension: openai.chatgpt-26.422.21459-linux-x64
• VS Code: 1.117.0
• VS Code commit: 10c8e557c8b9f9ed0a87f61f1c9a44bde731c409
• VS Code architecture: x64
• Fedora: Fedora release 43 (Forty Three)
• GNOME Shell: 49.6
• Kernel: Linux 6.19.13-200.fc43.x86_64 x86_64

The current log flood captured this time is different from the open-in-targets error from my earlier workaround report. In this capture, the dominant repeated warning is:

2026-04-24 11:34:00.986 [warning] worker_rpc_response_error error={} method=stable-metadata workerId=git

Counts from one captured Codex log snapshot:

worker_rpc_response_error: 13006
method=stable-metadata workerId=git: 13006
thread-stream-state-changed: 178
open-in-target not supported: 0
local-environments is not supported: 0
no-client-found: 0

Representative tail sample:

2026-04-24 11:35:48.236 [warning] worker_rpc_response_error error={} method=stable-metadata workerId=git
2026-04-24 11:35:48.248 [warning] worker_rpc_response_error error={} method=stable-metadata workerId=git
2026-04-24 11:35:48.254 [warning] worker_rpc_response_error error={} method=stable-metadata workerId=git
2026-04-24 11:35:48.270 [warning] worker_rpc_response_error error={} method=stable-metadata workerId=git
2026-04-24 11:35:48.275 [warning] worker_rpc_response_error error={} method=stable-metadata workerId=git

One thing that makes this hard to diagnose is that the warning logs error={}, so the underlying exception/message is not visible.

I also checked the installed out/extension.js. It looks like open-in-targets now has a safe fallback:

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

But these local environment handlers still throw:

"local-environment":async()=>{throw new Error("local-environment is not supported in the extension")}
"local-environments":async()=>{throw new Error("local-environments is not supported in the extension")}

So this capture shows a definite new log/CPU problem: a repeated extension-side loop around the internal git worker stable-metadata request.

I do not want to claim yet that the earlier unsupported-route issue is fully solved. I have not used this newer extension build enough to confirm that. It may simply not have been triggered in this session. What I can say from this capture is:

• the current visible flood is different and appears new
• open-in-targets now appears to have a safe fallback in the installed extension
• local-environment / local-environments still throw in the installed extension
• I have not confirmed whether the older unsupported-route behavior is gone in all flows

Suggested follow-up:

1. Log the real underlying error for worker_rpc_response_error instead of error={}.
2. Rate-limit or deduplicate repeated identical worker warnings.
3. Investigate why stable-metadata is repeatedly failing in the extension git worker.
4. Consider returning safe fallback responses for local-environment / local-environments as well, instead of throwing.

High Cpu usage still again with Codex Visual Studio Code extension: 26.422.21459 on Mac Book Pro 2019 - Intel i7

Visual studio:
Versione: 1.117.0
Commit: 10c8e557c8b9f9ed0a87f61f1c9a44bde731c409
Data: 2026-04-21T16:12:14-07:00 (3 giorni fa)
Electron: 39.8.7
ElectronBuildId: 13841579
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
Sistema operativo: Darwin x64 25.3.0

Hi _everyone_, I’m very happy to be able to help you @shijie-oai improve the product and support the community.
Unfortunately, I can’t provide the session IDs because they were deleted.

My old version patch Comment#1 no longer works (which makes _sense_, as now there’s a different issue). Its described here Comment#2.

Sorry I’m not _hinting at anything_, but I’m not a project contributor.

I’ve also updated the patch https://gist.github.com/GoXLd/cdbaa5598df152d1ef63feec4c50a717
!!!Attention: if you applied it earlier, you’ll need to use --force.

I have some ideas about a fix.

The main change is this replacement:

s/async handleResolveStableMetadata\(r,\{appServerClient:n\}\)\{.*?\}(?=async handleUpstreamBranch\()/async handleResolveStableMetadata(r,{appServerClient:n}){let o={commonDir:r.cwd,root:r.cwd};return ne(o)}/sg; 

It replaces the original implementation of handleResolveStableMetadata(...) with a simplified version that always constructs metadata from the current working directory (r.cwd) and returns it through ne(o).

In practice, this bypasses the previous resolution logic and forces stable metadata to resolve locally instead of following the old code path, which appears to be related to the new issue (including the request loop / excessive request behavior).

Have a great weekend!

Please kindly help them to fix it - the same problem persists on Ubuntu
24.04.

I rolled back to 4 weeks old Codex extension which still occasionally has
this problem but unlike with the later versions, it can be resolved by
window reload.

On Fri, 24 Apr 2026, 21:25 Alexandre VANDEMOORTELE, <
@.***> wrote:

GoXLd left a comment (openai/codex#16231) Hi everyone , I’m very happy to be able to help you @shijie-oai improve the product and support the community. Unfortunately, I can’t provide the session IDs DuckDuckGo removed one tracker. More <https://duckduckgo.com/-uyJBtpcquAi8mzROiHm6tw9LVd51p4w6GyxQ9tV2zg_afuJloZBFEEuBY27KxaGwrwqL64X_-Qv-gD0ivbS0hsR5BoJfabTv7pTVwbafFgK6d5GBYqZnJqjbDuEWAoQWLA23GOdBBBzycPdPiBBp0xlroSQBgwix2VwksDGdPb_vzC32JfKp_fJeL7-ukUJbOudkND3MVaOB5aG-6v5pUt98w5PGOQmIInPf-XgjCHOMEUru37DcFUX3qhIxX3zcrz4_P_iIWfj9VPJjv32gvVSZspjS4fesLg5K_sXFKExgCDckAPFuo4-ShhR0mQoJkxsEnYKp0-4MysIxWoySUPFFgF8anfMS5sRwwBh92FIygpRksa1NpqKpEbGJ7fcoFwP8CT5ho7D_Z6CluPktcZhFIcL9DPpNSzARgkl9w1tIG6cO9usc4F4xF7u-XpDO2nraLJTYsrrI3iPuBr9FRQ5L6_hq17Bwjql1lK9ZuEKofw5eFT__-FSSpX5rvBIbPhcWrpcVXJa5CDBGTNugA> Report Spam <https://duckduckgo.com/-uyJBtpcquAi8mzROiHm6tw9LVd51p4w6GyxQ9tV2zg_afuJloZBFEEuBY27KxaGwrwqL64X_-Qv-gD0ivbS0hsR5BoJfabTv7pTVwbafFgK6d5GBYqZnJqjbDuEWAoQWLA23GOdBBBzycPdPiBBp0xlroSQBgwix2VwksDGdPb_vzC32JfKp_fJeL7-ukUJbOudkND3MVaOB5aG-6v5pUt98w5PGOQmIInPf-XgjCHOMEUru37DcFUX3qhIxX3zcrz4_P_iIWfj9VPJjv32gvVSZspjS4fesLg5K_sXFKExgCDckAPFuo4-ShhR0mQoJkxsEnYKp0-4MysIxWoySUPFFgF8anfMS5sRwwBh92FIygpRksa1NpqKpEbGJ7fcoFwP8CT5ho7D_Z6CluPktcZhFIcL9DPpNSzARgkl9w1tIG6cO9usc4F4xF7u-XpDO2nraLJTYsrrI3iPuBr9FRQ5L6_hq17Bwjql1lK9ZuEKofw5eFT__-FSSpX5rvBIbPhcWrpcVXJa5CDBGTNugA> GoXLd left a comment (openai/codex#16231) <https://github.com/openai/codex/issues/16231#issuecomment-4315394820> Hi everyone, I’m very happy to be able to help you @shijie-oai <https://github.com/shijie-oai> improve the product and support the community. Unfortunately, I can’t provide the session IDs because they were deleted. My old version patch #16231 (comment) <https://github.com/openai/codex/issues/16231#issuecomment-4205506808> no longer works (which makes sense, as now there’s a different issue). Its described here #16231 (comment) <https://github.com/openai/codex/issues/16231#issuecomment-4307134084>. Sorry I’m not hinting at anything, but I’m not a project contributor. I’ve also updated the patch https://gist.github.com/GoXLd/cdbaa5598df152d1ef63feec4c50a717 if you applied it earlier, you’ll need to use --force. I have some ideas about a fix. Have a great weekend! — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/16231#issuecomment-4315394820>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AVQEHVVQ7QXYNM6Q243MAK34XOWR7AVCNFSM6AAAAACXFWTH56VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGMJVGM4TIOBSGA> . You are receiving this because you commented.Message ID: @.***>

pre-release 26.5422.30944 fixed it for me

Same problem continues on Linux. Quantitative follow-up to my earlier comment.

I upgraded from 26.325.21211 to the latest 26.422.30944 on Ubuntu 24.04 (VS Code 1.115.0, x64). Same runaway pattern as before, but it now surfaces under 4 minutes after the upgrade instead of after hours of uptime.

| | 26.325.21211 (yesterday) | 26.422.30944 (today) |
|--- |--- |--- |
| Time-to-runaway | ~9.5 h uptime | < 4 min post-upgrade |
| etime / cputime at detection | 9h 33m / 9h 52m | 03:46 / 04:43 (ratio 1.25) |
| Instantaneous %CPU | 103% | 125% |
| Process signature | code --type=zygote renderer | identical |

Diagnostic note for Linux triage: the runaway renderer does not appear in Help → Open Process Explorer even though its ppid chain traces to the main code process. We verified this manually 7 times. Identification has to be done at the OS level — ps -C code -o pid,etime,time and look for any zygote where cputime ≈ etime. Sharing in case it helps others fix the problem.

I've rolled back to 26.325.21211. The newest version 26.422.30944 replaces "occasional slow burn, recoverable via window reload" (v26.325.21211) with "minute-scale repeatable runaway" — much worse.

Environment: Ubuntu 24.04.4 LTS, kernel 6.17.0-22-generic, VS Code 1.115.0, x64.

26.5422.30944 still has the issue. Applying workaround patch in https://gist.github.com/GoXLd/cdbaa5598df152d1ef63feec4c50a717 worked.
If you are using Antigravity with Codex plugin, add/update this to the fix:

roots=(
  "$HOME/.vscode/extensions"
  "$HOME/.vscode-insiders/extensions"
  "$HOME/.antigravity/extensions"
)

26.5422.30944 still has the issue. Applying workaround patch in https://gist.github.com/GoXLd/cdbaa5598df152d1ef63feec4c50a717 worked. If you are using Antigravity with Codex plugin, add/update this to the fix

Thanks for your report. I’ve updated the fix to include Antigravity extension installs as well:

```
"$HOME/.vscode/extensions"
"$HOME/.vscode-insiders/extensions"
"$HOME/.antigravity/extensions"

And updated the process check so the script now blocks patching when VS Code, VS Code Insiders, or Antigravity is running:
**[patch-openai-chatgpt-extension-CODEX-arm64.sh](https://gist.github.com/GoXLd/cdbaa5598df152d1ef63feec4c50a717)**

Latest version(s) in macOS still burn 110+% on multiple cores at all times, sitting idle.

High CPU in VS Code renderer when Codex is opened in a folder without Git

Hi! I found a reproducible high CPU issue with the Codex VS Code extension.

The problem seems to happen when Codex is opened in a workspace folder that is not a Git repository root. If I open a folder that has .git directly in the workspace root, the CPU usage stays normal.

Environment

• macOS
• Apple Silicon / arm64
• VS Code installed at /Applications/Visual Studio Code.app
• Codex / OpenAI ChatGPT VS Code extension
• Installed extension folder on my machine: ~/.vscode/extensions/openai.chatgpt-26.422.30944-darwin-arm64

The process that consumes CPU is not the extension host. It is:

Code Helper (Renderer)

In VS Code Process Explorer it appears as:

window    100%+ CPU

What happens

When I open Codex in a folder without .git in the workspace root, CPU usage jumps to around 100% or more and stays there.

Closing the Codex panel does not stop the CPU usage. The renderer process keeps consuming CPU even after the Codex UI is closed.

The extension host itself stays relatively low, so this looks like a renderer / webview issue rather than normal extension-host CPU usage.

What I tested

I first checked VS Code without extensions:

code --new-window --disable-extensions

CPU usage was normal.

Then I tested a clean VS Code profile with only the Codex extension installed:

code --user-data-dir /tmp/vscode-clean-user --extensions-dir /tmp/vscode-clean-ext

With only Codex installed, I tested different folders.

My workspace looks like this:

~/ProgC
├── command
├── ssh_messenger
└── Univ
    └── labs
        └── .git

These folders are not Git repository roots:

cd ~/ProgC/command
git rev-parse --show-toplevel

fatal: not a git repository (or any of the parent directories): .git

cd ~/ProgC/ssh_messenger
git rev-parse --show-toplevel

fatal: not a git repository (or any of the parent directories): .git

cd ~/ProgC/Univ
git rev-parse --show-toplevel

fatal: not a git repository (or any of the parent directories): .git

This folder is a Git repository root:

cd ~/ProgC/Univ/labs
git rev-parse --show-toplevel

/Users/artem/ProgC/Univ/labs

Results

Here are the results I got:

Clean profile + only Codex + empty folder without .git -> CPU high
Clean profile + only Codex + ~/ProgC/command -> CPU high
Clean profile + only Codex + ~/ProgC/ssh_messenger -> CPU high
Clean profile + only Codex + ~/ProgC/Univ -> CPU high
Clean profile + only Codex + ~/ProgC/Univ/labs -> CPU low

So the deciding factor seems to be whether the opened workspace folder itself is a Git repository root.

Workspace size

The workspace is small, so I do not think this is caused by a large project:

cd ~/ProgC
find . -type f | wc -l

753

find . -type d | wc -l

280

du -sh .

3.3M    .

Expected behavior

Codex should work normally in a folder that is not a Git repository.

If Git metadata is needed, the extension should handle a non-Git workspace without entering a high CPU loop.

Actual behavior

Opening Codex in a non-Git workspace causes sustained high CPU usage in:

Code Helper (Renderer)

The CPU usage continues even after closing the Codex panel.

Workaround

Opening the actual Git repository root fixes the issue.

For example, this causes high CPU for me:

code ~/ProgC/Univ

But this works normally:

code ~/ProgC/Univ/labs

because ~/ProgC/Univ/labs contains .git.

Another workaround is to initialize Git in the opened folder:

cd /path/to/project
git init

After that, Codex no longer seems to trigger the high CPU behavior for that folder.

The problem seems to happen when Codex is opened in a workspace folder that is not a Git repository root. If I open a folder that has .git directly in the workspace root, the CPU usage stays normal.

THANK YOU!

Initializing a repo at the workspace level instantly brought CPU usage down.

Just to confirm, _git init_ in root instantly dropped CPU. Ubuntu, latest Codex extension version. Thank you.

after all these fixes/releases i keep updating to the latest codex and then the cpu goes wild. It's at 260% this time after installing the new latest version.

It was half working without cpu spiking for a short while, but wouldn't actually load any previous chats. So I had to roll back to finish old conversations.

I had upgraded yesterday and wasn't seeing the cpu spike, but now just installed the latest vscode and its reloaded and gone mental with cpu.

Every time I have to roll back to 26.313.41036, but now that approach is affecting me because I can't access the latest models.

Its been a month now of this instability. It seems like there are half a dozen different issues that have bubbled up all claiming to be causing the 100% with bad logging, problems with git needing to be initialised, some people saying 2nd windows are the cause. Have you lost control of the codebase?

i think if they just copy paste this url in codex and let codex fix it it should be fixed already lol

Dear codex team, any update on this issue?

For me, I've been running the latest versions now for a few weeks and not see my laptop emulate the surface of the sun.

For me, I've been running the latest versions now for a few weeks and not see my laptop emulate the surface of the sun.

without git repo root ? @rtpHarry

no all my projects have git in them

It still trying to melt my macbook, I really dont understand how this can be so long without fix...

It's already fixed. Just update to the latest version of vscode and the extension. It's fixed for me.

It's already fixed. Just update to the latest version of vscode and the extension. It's fixed for me.

trying using in non git repo and confirm. @DEBA1801

Closing as a duplicate of #7972.