You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Performance: Code Helper (Renderer) exceeds 100% when Codex applies a code patch in VS Code #15764
I’ve also encountered the same issue. The resource usage remains very high, and even after the conversation has ended, the related process continues to stay at a high level. In most cases, disabling the extension or restarting the application is necessary to restore things to normal.
Been having the same issue with the overheating a macbook air m4 using codex on vs code. The only workaround I've found was to use the official codex app for mac. It's not overheating when using the app, but now I have to keep switch apps between the Codex app and Vs code app.
Been having the same issue with the overheating a macbook air m4 using codex on vs code. The only workaround I've found was to use the official codex app for mac. It's not overheating when using the app, but now I have to keep switch apps between the Codex app and Vs code app.
My local VSCode installation with Codex has been behaving this way every day since I first installed Codex. I feel like its potentially shortening the life of my device, would hate for OpenAI to have a class action lawsuit related to thousands or millions of damaged work devices and associated hardware as a result of this fault; cutting 2-3 years off of a maintenance and replacement cycle is no small matter at a national or global scale.
Windows 11, latest version of VSCode and Codex plugin, I don't use the CLI version. CPU load behaviour been happening pretty consistently for months, sometimes just opening the VSCode app is enough to do it without starting any chat with Codex, truly a bizarre use of my system resources that has been unpatched far too long.
My local VSCode installation with Codex has been behaving this way every day since I first installed Codex. I feel like its potentially shortening the life of my device, would hate for OpenAI to have a class action lawsuit related to thousands or millions of damaged work devices and associated hardware as a result of this fault; cutting 2-3 years off of a maintenance and replacement cycle is no small matter at a national or global scale.
Windows 11, latest version of VSCode and Codex plugin, I don't use the CLI version. CPU load behaviour been happening pretty consistently for months, sometimes just opening the VSCode app is enough to do it without starting any chat with Codex, truly a bizarre use of my system resources that has been unpatched far too long.
Yes, beyond frustrating.
The class action comment made me smile, but the concern is valid. This has been going on for months now, there are many reports, and the pattern is consistent: excessive CPU, heat, fan noise, battery drain, and machines getting hammered during normal use.
At this point the product is unusable for many people, and if teams with hundreds of engineers are hitting this too, then it is not just an annoying bug, it is a real operational and hardware-impact issue at scale.
OpenAI needs to stop letting this sit and actually prioritize fixing it.
A rather blunt-force workaround is to restart VSCode's extension host: ctrl + shift + p opens up the command palette, then you want Developer: Restart Extension Host
That will restart all of your extensions so it might cause problems with them afterwards, but I've not found a way to properly restart just a single extension yet - but that's a VSCode problem
Here is a trick: if you opne a new thread, it consumes back to 0%. But if you jsut reopen old thread, it is back to 100%. So there is some bug in rendering answer
Reacted by José Souza, mouse, Nathan Whittle, Cesar Sanz, Mikko Rantalainen, shuhung and Ignat Remizov
"Code Helper (Renderer)" goes to ~100–120% CPU (sometimes higher)
In VS Code Process Explorer, the "window" process is the one consuming CPU (~110%)
The issue appears when the Codex panel/chat is open
"codex app-server" process remains at 0% CPU
Downgrading to 26.318.11754 completely resolves the issue. This looks like a regression introduced after 26.318.x, specifically affecting the renderer/webview layer.
Reacted by Steven DuBois, louisgls, Ignat Remizov, Guilhem Vellut and JohnZhangYH63
Activity
github-actions commentedon Mar 25, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Ralayax commentedon Mar 25, 2026
Same issue for me
pshenychnyi-maks commentedon Mar 25, 2026
the same
jeremiahodom commentedon Mar 26, 2026
Same issue
8 remaining items
Sheng-Charles commentedon Mar 30, 2026
Codex app same here, the CPU hits 100% during coding and thinking. but the CLI runs perfectly smooth.
hello-nico-chan commentedon Mar 31, 2026
Same issue for me
mousehaozi commentedon Apr 1, 2026
I’ve also encountered the same issue. The resource usage remains very high, and even after the conversation has ended, the related process continues to stay at a high level. In most cases, disabling the extension or restarting the application is necessary to restore things to normal.
sylvio-cavalcanti commentedon Apr 1, 2026
Been having the same issue with the overheating a macbook air m4 using codex on vs code. The only workaround I've found was to use the official codex app for mac. It's not overheating when using the app, but now I have to keep switch apps between the Codex app and Vs code app.
mousehaozi commentedon Apr 2, 2026
Yes, the desktop app of codex doesn't get hot
AmShaegar13 commentedon Apr 2, 2026
This is not limited to MacOS. Arch Linux here with high load after changing a file using the VS Code extension.
araydefence commentedon Apr 4, 2026
My local VSCode installation with Codex has been behaving this way every day since I first installed Codex. I feel like its potentially shortening the life of my device, would hate for OpenAI to have a class action lawsuit related to thousands or millions of damaged work devices and associated hardware as a result of this fault; cutting 2-3 years off of a maintenance and replacement cycle is no small matter at a national or global scale.
Windows 11, latest version of VSCode and Codex plugin, I don't use the CLI version. CPU load behaviour been happening pretty consistently for months, sometimes just opening the VSCode app is enough to do it without starting any chat with Codex, truly a bizarre use of my system resources that has been unpatched far too long.
cckalen commentedon Apr 4, 2026
Yes, beyond frustrating.
The class action comment made me smile, but the concern is valid. This has been going on for months now, there are many reports, and the pattern is consistent: excessive CPU, heat, fan noise, battery drain, and machines getting hammered during normal use.
At this point the product is unusable for many people, and if teams with hundreds of engineers are hitting this too, then it is not just an annoying bug, it is a real operational and hardware-impact issue at scale.
OpenAI needs to stop letting this sit and actually prioritize fixing it.
hydrandt commentedon Apr 7, 2026
Any workaround found? Debian Sid here.
For me it is:
/usr/share/code/code --type zygote/proc/self/exe --type=utility --utility-sub-type=node.mojom.NodeServicenrwhittle-beauhurst commentedon Apr 7, 2026
A rather blunt-force workaround is to restart VSCode's extension host:
ctrl + shift + popens up the command palette, then you wantDeveloper: Restart Extension HostThat will restart all of your extensions so it might cause problems with them afterwards, but I've not found a way to properly restart just a single extension yet - but that's a VSCode problem
kostiantyn-samkovskyi commentedon Apr 7, 2026
Here is a trick: if you opne a new thread, it consumes back to 0%. But if you jsut reopen old thread, it is back to 100%. So there is some bug in rendering answer
leonardo-r-rocha commentedon Apr 13, 2026
I’m experiencing a similar issue
Environment:
Symptoms:
Downgrading to 26.318.11754 completely resolves the issue. This looks like a regression introduced after 26.318.x, specifically affecting the renderer/webview layer.
Rohlik commentedon Apr 15, 2026
Seeing this also on my laptop with Ubuntu 24.04.
snz2 commentedon Apr 22, 2026
It was resolved after installing the latest version (26.5415.20818).