Codex extension makes VS Code extremely slow and overheats my computer

+1

_Note: I noticed that when running tests directly from Codex, the processes don’t finish properly because multiple Node.js executions remain open. After I killed those processes manually, everything went back to normal._

+1
My MacBook's power consumption went crazy just from installing the extension. Even though I was using Codex with the CLI, my VS Code was using three times more power than without the extension.

+1 same issue while using Codex extension in VSCode both on MacBook Air M1 and on PC with WSL2

+1

+1

+1

Large monorepo, M4 Pro, there is a 0.5-1s lag using the VS Code text editor after installing codex after every click / highlight of text, rendering productive work almost impossible

Version: 0.5.35 (pre-release)

Also noticing "Code Helper (Renderer)" taking 50%+ CPU but cannot say if this is new right now.

Have not tried smaller repo.

+1

+1

resolved by deleting extension

+1
i though it was my laptop, in a way it was because of CPU usage but then upgraded to BEAST CPU and guess what, same issue after some chatting and implementations

+1

It lags the longer the chat back and forth is, the higher the lag is.
Deffo probably something wrong with either how large text is rendered/handled or something weird in the way its structured.

Yes, long contexts cause severe lag for me on Linux with VS Code from the AUR. There have been a handful of updates come through but none of them have addressed this.

But then again OpenAI is only a small company... /s

+1
In JetBrains IDE, its the same problem. Ram and CPU are filling up and IDE is responding extremely slow, if Codex is reading files, and the bigger the file, the exponentually longer it takes to read the file. If it read every file, it works nicely again tho.

Yeah, for me, I get very large delays when switching between threads. It seems to be an issue related to the fact that the entire thread seems to be loaded in, rather than just the last part. Cursor's own AI chat system loads only the most recent messages, and hydrates as one scrolls up.

I had this problem until I switched from Intel MacBook to Apple Silcon. Hasn't happened since. Unless you reload a long chat, it causes VSCode to stop responding a few times, and have to click keep waiting.

Yeah, that reloading a long chat is the exact problem that I'm having. It isn't a deal-breaker, but it makes navigating between long chat sessions quite excruciating. It would be fixed by just loading the last part of the chat and hydrating as you scroll, the way Cursor does.

I have a problem with codex on Windows 10. Never had before but lately I have this problem and it is very hard to work. It usually slows down when start to read big files. The CPU go high, Pycharm start to eat all the RAM that it can and if clicking on Expand, I can see that it reads the file on small chunks and very very slow.

Sometimes that helps me is stopping it (it will stop in one minute because IDE is completely inaccessible), and I ask it to continue from the point where it stopped.

Update: After upgrading it started to be way better

For me codex is crashing the VSCode all the time. Did the crash log analysis with Claude, and here's the summary:

<h3 style="line-height: normal; font-size: 13px; font-weight: 600; margin: 1.5em 0px 0.875em; font-family: -apple-system, &quot;system-ui&quot;, sans-serif; color: rgb(204, 204, 204); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(33, 37, 43); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">Primary cause:<span> </span><strong style="font-weight: 600;">Copilot Chat listener/document model leak (renderer-side)</strong></h3><p style="margin: 0px 0px 16px; color: rgb(204, 204, 204); font-family: -apple-system, &quot;system-ui&quot;, sans-serif; font-size: 13px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(33, 37, 43); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">Every time Copilot Chat invokes a tool (<code style="font-family: &quot;SF Mono&quot;, Monaco, Menlo, Courier, monospace; font-size: 10.998px; color: rgb(215, 186, 125); background-color: rgba(255, 255, 255, 0.1); padding: 1px 3px; border-radius: 4px; border-color: rgb(215, 186, 125); border-style: none; border-width: 0px; border-image: none 100% / 1 / 0 stretch; white-space: pre-wrap;">read_file</code>,<span> </span><code style="font-family: &quot;SF Mono&quot;, Monaco, Menlo, Courier, monospace; font-size: 10.998px; color: rgb(215, 186, 125); background-color: rgba(255, 255, 255, 0.1); padding: 1px 3px; border-radius: 4px; border-color: rgb(215, 186, 125); border-style: none; border-width: 0px; border-image: none 100% / 1 / 0 stretch; white-space: pre-wrap;">apply_patch</code>, etc.), it calls<span> </span><code style="font-family: &quot;SF Mono&quot;, Monaco, Menlo, Courier, monospace; font-size: 10.998px; color: rgb(215, 186, 125); background-color: rgba(255, 255, 255, 0.1); padding: 1px 3px; border-radius: 4px; border-color: rgb(215, 186, 125); border-style: none; border-width: 0px; border-image: none 100% / 1 / 0 stretch; white-space: pre-wrap;">$tryOpenDocument</code><span> </span>and<span> </span><code style="font-family: &quot;SF Mono&quot;, Monaco, Menlo, Courier, monospace; font-size: 10.998px; color: rgb(215, 186, 125); background-color: rgba(255, 255, 255, 0.1); padding: 1px 3px; border-radius: 4px; border-color: rgb(215, 186, 125); border-style: none; border-width: 0px; border-image: none 100% / 1 / 0 stretch; white-space: pre-wrap;">vie._createModifiedFileEntry</code>, which creates text editor models (<code style="font-family: &quot;SF Mono&quot;, Monaco, Menlo, Courier, monospace; font-size: 10.998px; color: rgb(215, 186, 125); background-color: rgba(255, 255, 255, 0.1); padding: 1px 3px; border-radius: 4px; border-color: rgb(215, 186, 125); border-style: none; border-width: 0px; border-image: none 100% / 1 / 0 stretch; white-space: pre-wrap;">WF</code>/<code style="font-family: &quot;SF Mono&quot;, Monaco, Menlo, Courier, monospace; font-size: 10.998px; color: rgb(215, 186, 125); background-color: rgba(255, 255, 255, 0.1); padding: 1px 3px; border-radius: 4px; border-color: rgb(215, 186, 125); border-style: none; border-width: 0px; border-image: none 100% / 1 / 0 stretch; white-space: pre-wrap;">LYe</code>/<code style="font-family: &quot;SF Mono&quot;, Monaco, Menlo, Courier, monospace; font-size: 10.998px; color: rgb(215, 186, 125); background-color: rgba(255, 255, 255, 0.1); padding: 1px 3px; border-radius: 4px; border-color: rgb(215, 186, 125); border-style: none; border-width: 0px; border-image: none 100% / 1 / 0 stretch; white-space: pre-wrap;">Bu</code>) with event listeners that<span> </span><strong style="font-weight: 600;">are never disposed</strong>. This is a renderer-process leak — it<span> </span><strong style="font-weight: 600;">survives extension host restarts</strong>.</p><p style="margin: 0px 0px 16px; color: rgb(204, 204, 204); font-family: -apple-system, &quot;system-ui&quot;, sans-serif; font-size: 13px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(33, 37, 43); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">Timeline from the log:</p><div class="monaco-scrollable-element mac rendered-markdown-table-scroll-wrapper" role="presentation" style="width: 339.004px; margin-bottom: 16px; color: rgb(204, 204, 204); font-family: -apple-system, &quot;system-ui&quot;, sans-serif; font-size: 13px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; background-color: rgb(33, 37, 43); text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; position: relative; overflow: hidden;"><div style="overflow: hidden;">
</div></div>

Time | Listener count | Note
-- | -- | --
19:52:03 | 175 → 200 | Growing
20:00:05 | 224 | Copilot Chat active
20:01:33 | 244 | Still growing
20:01:44 | — | InstantiationService disposed (Copilot Chat tool stream on dead service)
20:05:12 | 282 → 284 | Peak before crash #1
20:05:28 | CRASH | Exit code 6 (OOM)
20:06:15 | 199 → 290 | Right after restart — leaks persist in renderer!
20:50:27 | 400 | Terminal listener leak (createDetachedTerminal)
20:49:43 | CRASH | Exit code 5 (OOM)

PS: not sure if it's all codex fault but the VSCode has become unusable when debugging nextjs application at the same time

+1

After a codex prompt has finished, I get very high cpu activity, with a baseline around 5% to 40% cpu usage per physical core. It does not seem to stop after the promt and there is nothing else running on the machine.

<img width="2208" height="404" alt="Image" src="https://github.com/user-attachments/assets/356d8d79-7d76-43c1-ad04-425d12d74503" />

Follow up since the last time, its seems the main cause is either the code blocks inside the chat section or the terminal runs, because i can go for hours in normal conversation with thousands of token generated but as soon as it start generating code it lags out, when i close an re-open VS code then because all the code blocks are gone then it will works with no problems

+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

<img width="385" height="79" alt="Image" src="https://github.com/user-attachments/assets/b915f9e7-6269-428e-b464-4433be5300dd" />

+1

Why does EVERY OpenAI tool on MacOS consume massive amounts of CPU when completely idle? Like, it's not even funny, it's pathetic. I've never encountered a worse experience in this regard.

OpenAI may have the best AI engineers in the world but their consumer facing software developers are a laughingstock. Congratulations guys. You have the easiest engineering job at OpenAI and you're blowing it.

+1
I’m seeing very high CPU usage (~150%+) in Visual Studio Code when the Codex extension is enabled.

The load is mainly from window / Code Helper (Renderer), not extension host
My Mac gets very hot and fans spin up quickly
Disabling Codex immediately brings CPU back to normal

It doesn’t seem tied to a specific file — feels like something is continuously running in the renderer (possibly context scanning or UI updates).

I found a way to mitigate the issue I was hitting.

As of version 26.415.20818, simply enabling the extension could keep CPU usage at 150%+ continuously, even when I was not actively doing anything. By comparison, the standalone Codex CLI did not show the same behavior. Because of that, I suspected the problem was in the VS Code frontend extension rather than in Codex itself.

I used Codex to debug some of the built bundle files and apply an experimental fix. In my case, it significantly reduced CPU usage to under 10%, and the temperature / fan noise issue went away as well. I also did not notice any obvious loss of core Codex extension functionality, although there may still be side effects.

The basic workflow was:

1. cd ~/.vscode/extensions/openai.chatgpt-{version}
2. use an AI CLI tool and provide the following prompt

Below is the prompt I exported, followed by the main solution ideas suggested by the AI.

Suggested Prompt For AI Coding Tools

Investigate high CPU usage in the VS Code renderer for the Codex/OpenAI extension webview.

Assume the issue is primarily in the webview frontend, not the extension host.

Focus on these classes of problems:
- query polling
- refetchOnWindowFocus / background refetch
- broad global subscriptions
- cross-webview query invalidation broadcasts
- high-frequency streaming flushes
- immediate or near-immediate scheduler loops such as setTimeout(0), microtask storms, or requestAnimationFrame-heavy refresh loops

Goal:
- reduce sustained renderer CPU usage
- prefer event-driven refresh over polling where possible
- batch frontend updates more aggressively
- accept some loss of UI immediacy if needed

Please:
1. identify the hottest renderer-side refresh loops
2. reduce or disable unnecessary polling
3. disable or narrow global invalidation fan-out
4. reduce streaming flush frequency
5. slow down or coarsen the internal query scheduler if it is creating a steady batch storm
6. clearly document user-visible tradeoffs

Summary

The high CPU issue was not primarily in the extension host. It was in the webview renderer.

The main problem was overly aggressive frontend synchronization:

• frequent query invalidation
• broad global subscriptions
• background/window-focus refetches
• cross-webview query-cache broadcasts
• high-frequency streaming state flushes
• an internal query scheduler that used immediate or near-immediate re-scheduling

This created sustained renderer load in Code Helper (Renderer), especially in the Codex webview.

What Was Changed

The following experimental patches were applied directly to the built webview bundles:

1. Reduced telepathy-permissions refresh aggressiveness

• lowered polling frequency
• disabled background refetch
• disabled refetch-on-window-focus
• removed refresh on codex-app-server-connection-changed

1. Disabled global live subscriptions for recent conversations

• removed addAnyConversationCallback
• removed addAnyConversationMetaCallback
• disabled focus-triggered refetch for recent conversation queries

1. Disabled cross-webview query invalidation broadcast

• stopped sending query-cache-invalidate
• ignored received query-cache-invalidate
• kept only local invalidation in some mutation flows

1. Reduced streaming UI flush frequency

• increased fallback flush interval for conversation deltas
• made streaming updates less frequent and more batched

1. Reworked the internal query/state scheduler

• original behavior effectively used immediate rescheduling
• changed first to frame-based / delayed scheduling
• later changed to coarse setTimeout(..., 50) batching

1. Removed several constant polling queries

• primary-runtime-update-status
• ambient-suggestions-generation-statuses
• debug child-processes

These were changed from interval-driven refresh to action/event-driven refresh where possible.

Result

This significantly reduced renderer CPU usage.

Across multiple traces, the hot path moved from:

• TimerFire
• RunMicrotasks
• Ee -> batch -> #s -> fetch/onPause/onSubscribe

to much lower and more manageable renderer activity.

In short:

• the original setTimeout(0) / immediate scheduling storm was a major contributor
• reducing polling and broad invalidation helped
• moving high-cost refresh paths toward event-driven updates helped further

Tradeoffs / Side Effects

These changes are intentionally biased toward lower CPU, not maximum UI immediacy.

Possible side effects:

• streaming output may feel less real-time
• some UI updates may appear in larger batches
• recent conversations may not refresh immediately everywhere
• cross-panel/webview state sync may be weaker
• status views that previously refreshed automatically may now update only after actions/events
• debug panels may feel more static

Important Note

This was an experimental patch applied to compiled bundle files, not a clean source-level refactor.

It demonstrates a likely correct direction for an upstream fix:

• reduce polling
• reduce broad subscriptions
• reduce or remove cross-webview invalidation broadcast
• replace aggressive auto-refetch with event-driven refresh
• avoid immediate query rescheduling loops in the renderer