Codex Windows 26.623.70822 consumes CPU continuously while idle in system tray and appears to trigger Defender activity
Codex Windows 26.623.70822 consumes CPU continuously while idle in system tray and appears to trigger Defender activity
Hello OpenAI / Codex team,
I am reporting a performance issue with the Codex Windows desktop application. Codex appears to consume CPU continuously while idle, including when minimized to the Windows system tray and no task is running. Microsoft Defender also appears to become more active while Codex is open, which amplifies the total CPU load and causes sustained fan noise.
Summary
Codex for Windows consumes around 1-3% total CPU continuously while idle, even immediately after startup, with:
- no user-initiated task running;
- no active prompt;
- no visible agent/tool activity;
- the application minimized to the Windows system tray.
This causes a practical usability issue on my laptop: fans ramp up and remain noisy even though Codex is only open in the background.
Why this may be distinct from related reports
I found related high-CPU / idle reports, but this case may add useful signal because the issue:
- reproduces immediately after launching Codex, before any task is started;
- persists even when Codex is minimized to the Windows system tray;
- still reproduces after temporarily disabling Microsoft Defender real-time protection;
- appears to correlate with increased Defender CPU activity when real-time protection is enabled.
Related issues that look adjacent:
- <https://github.com/openai/codex/issues/29281> - Windows 11 Codex idle fan noise / GPU/CPU activity.
- <https://github.com/openai/codex/issues/30021> - Windows desktop burns a CPU core while visible and idle.
- <https://github.com/openai/codex/issues/30527> - Windows / Defender activity while Codex is open.
- <https://github.com/openai/codex/issues/29499> - WMI Provider Host CPU activity after launching Codex.
- <https://github.com/openai/codex/issues/20567> - repeated background Git process spawning.
Codex version
Visible Codex app version:
- Codex 26.623.70822
- Released: June 29, 2026
Process observed consuming CPU:
C:\Program Files\WindowsApps\OpenAI.Codex_26.623.9142.0_x64__2p2nqsd0c76g0\app\Codex.exe
Another Codex-related process observed in Microsoft Defender performance data:
C:\Program Files\WindowsApps\OpenAI.Codex_26.623.9142.0_x64__2p2nqsd0c76g0\app\resources\codex.exe
Reproduction steps
- Start the Codex Windows desktop application.
- Do not start any Codex task.
- Do not submit a prompt.
- Do not interact with the application.
- Minimize Codex to the Windows system tray.
- Monitor CPU usage.
The CPU usage starts immediately after launching Codex and continues while the app is idle in the system tray.
Expected behavior
When Codex is open but idle, with no running task and no user interaction, CPU usage should be close to zero except for occasional short spikes.
Minimizing the app to the Windows system tray should make the app effectively idle and should not cause sustained fan noise.
Actual behavior
Codex continuously consumes CPU while idle.
Measured with the app open, minimized to the system tray, just after startup, with no user activity and no task requested:
- Measurement duration: 132.5 seconds
- Average Codex CPU usage: 1.45% total CPU
- Minimum instantaneous Codex CPU usage: 0.78% total CPU
- Maximum instantaneous Codex CPU usage: 2.14% total CPU
- Average number of Codex-related processes: 12
This behavior persists even when Codex is minimized to the system tray.
I also tested temporarily disabling Microsoft Defender real-time protection. Codex still continued to consume around 1-3% CPU while idle, which suggests that Codex itself has sustained background CPU activity.
Microsoft Defender interaction
When Codex is open, Microsoft Defender's MsMpEng.exe also appears to consume significantly more CPU, typically around 5-9% according to Windows Task Manager estimates.
When Codex is closed, MsMpEng.exe quickly returns to much lower CPU usage.
I was not able to obtain a reliable average CPU measurement for MsMpEng.exe, as PowerShell-based process CPU measurements did not work correctly for this protected Windows process. However, the behavior is clearly visible in Windows Task Manager.
A Microsoft Defender Performance Report showed Defender activity related to several Codex files and components, including:
Codex.exeresources\codex.exe- local Codex Node runtime:
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\...\bin\node_repl.exe- Codex session/cache files:
%USERPROFILE%\.codex\session_index.jsonl%USERPROFILE%\.codex\models_cache.json%USERPROFILE%\.codex\cache\...- Codex WebView / local cache files:
%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex\...- temporary JavaScript and CSS files under
%LOCALAPPDATA%\Temp
I also tested adding a targeted Microsoft Defender exclusion for:
%LOCALAPPDATA%\OpenAI\Codex\runtimes
The exclusion was correctly applied, but it did not reduce either Codex CPU usage or Microsoft Defender CPU usage. I then removed the exclusion.
This makes me think the root cause is not simply Defender scanning one specific runtime file. It looks more like Codex has continuous idle background activity, and Defender reacts to that activity.
User impact
The issue is very noticeable in day-to-day use:
- the laptop fans ramp up and remain noisy;
- the machine becomes unpleasant to use while Codex is merely open;
- this happens even when Codex is minimized to the system tray;
- this happens immediately after launching Codex, before any task is started;
- the issue makes it impractical to keep Codex open in the background.
System information
Relevant PC information:
- Device type: laptop / Windows PC
- CPU: 11th Gen Intel(R) Core(TM) i5-1145G7 @ 2.60GHz
- RAM: 16 GB
- GPU: Intel(R) Iris(R) Xe Graphics
- System type: 64-bit operating system, x64-based processor
- OS edition: Windows 11 Professional
- Windows version: 25H2
- OS build: 26200.8655
- Windows Feature Experience Pack: 1000.26100.315.0
- Storage usage: 232 GB used out of 238 GB
Additional diagnostic notes
The issue appears immediately after starting Codex and does not require opening a project or launching a task.
The main problem seems to be sustained idle CPU usage from Codex itself. Microsoft Defender appears to amplify the overall CPU load, but Codex still consumes CPU even when Defender real-time protection is temporarily disabled.
Potential areas to investigate:
- idle-loop or polling behavior in the Windows desktop app;
- WebView / renderer activity while idle or minimized to tray;
- background filesystem or cache writes that may trigger Defender scanning;
- telemetry or session-index updates while idle;
- local runtime or app-server processes that remain active without a task;
- repeated project/workspace discovery, Git checks, or process enumeration.
Could you please investigate whether Codex for Windows has an idle-loop, polling, WebView, telemetry, runtime, cache, or background-service issue that prevents the app from becoming truly idle when no task is running?
Thank you.
8 Comments
Codex 26.707.31428 still high CPU usage especially on process MsMpEng.exe
Windows 10 22H2 19045.7417
Ryzen 7 5700X / 64GB RAM / GTX 750
I have some data that ties this slowdown to Defender repeatedly scanning a file that other issues have flagged as being churned excessively by the ChatGPT/Codex Desktop app on both Windows and Mac platforms.
Environment
26.707.9981.0ChatGPT.exe4.18.26060.3008Finding
Across multiple ETL recordings, Defender repeatedly performs expensive real-time scans of Codex’s Sentry state file:
The file is only approximately 34 KB. The scans are initiated by
ChatGPT.exeand consistently report:Representative measurements:
| Recording | Scans | Aggregate scan time | Average | Median | Maximum |
|---|---:|---:|---:|---:|---:|
| Trace 1, 49.9-second observation | 29 | 38.61 s | 1,331 ms | 1,351 ms | 1,963 ms |
| Trace 2 | 25 | 42.35 s | 1,694 ms | — | 2,106 ms |
| Trace 3, 40.4-second observation | 16 | 18.66 s | 1,166 ms | — | 2,061 ms |
In Trace 2, Defender attributed 44.66 seconds of aggregate scan time to
ChatGPT.exe;scope_v3.jsonaccounted for 42.35 seconds of that total.This was repeatable across separate recordings. The file is being closed frequently enough that Defender repeatedly spends roughly 1–2 seconds scanning it. Aggregate scan duration can include overlapping work, but the file is consistently the dominant Defender hotspot.
Related report
This appears related to #32496, which reports excessive rewrite churn for
scope_v3.jsonon Codex26.707.41301, the same26.707release family:https://github.com/openai/codex/issues/32496
A detailed analysis in that issue suggests the bundled
@sentry/electronintegration persists the complete merged scope whenever breadcrumbs or context change. Its buffered store may write as often as every 500 ms and apparently does not compare the new content with the previously persisted content:https://github.com/openai/codex/issues/32496#issuecomment-4952001661
That report is macOS-focused and measures SSD writes. My traces provide a Windows-specific consequence: frequent
scope_v3.jsonrewrites trigger expensive DefenderOnClosescans and amplify total CPU use.This does not necessarily explain Codex’s own idle CPU usage when Defender is disabled, but it appears to explain a substantial portion of the additional
MsMpEng.exeload while Codex is running.Potential mitigations in the application would be:
scope_v3.jsonwhen its serialized content has not changed.I can provide the Defender ETL recordings privately if useful; they contain local process and filesystem metadata.
Additional deterministic reproduction: switching projects starts persistent CPU activity
I found a deterministic reproduction that appears to point to project-scoped background activity not being disposed when switching projects.
Environment
26.707.9981.019045, x64Reproduction steps
Expected behavior
When switching away from a project, project-specific background work such as Git polling, filesystem watchers, session/task synchronization, or rendering updates should stop. Switching back to an empty project should restore the original idle state without requiring an application restart.
Actual behavior
Once another project has been opened, sustained CPU activity continues after switching back to the empty project. Only a full process restart while the empty project is selected clears the CPU activity.
A local process-time sample after the problem was triggered showed that the activity was concentrated in the main
ChatGPT.exe, GPU, and renderer processes. The Codex app-server and Node/MCP helper processes contributed little or no CPU during the sample.Diagnostic implication
The application is capable of reaching a true idle state when it starts directly in an empty project. This suggests that opening another project creates project-scoped background activity that is not fully disposed when the active project changes.
Current workaround
The only reliable workaround I have found is:
Simply switching back to the empty project without restarting does not stop the CPU activity.
Same here. Working with the new ChatGPT app on a Windows laptop is very annoying now because the fan noise is constant.
Same here. I've noticed that ChatGPT appears to keep spawning a powershell script to check process IDs. I don't know if that's a red herring, or what's triggering Defender so badly.
Ver 26.707.72221
On an 8cpu 32GB Microsoft Cloud PC, the increase is while on the "New task" screen. All others (Projects, Scheduled, Plugins, Settings etc), the CPU drops. Does not stabalise when left for while - it's instance increase/decrease. Minimize, focus etc. no difference
Middle of the attached CPU graph is where I've switch context to the Projects screen.
New tab - ChatGPT avg 3.47, Defender avg 8.59
Projects - ChatGPT avg 0.02, Defender avg 0.36
May seem trivial, but that's over 10% of an 8 core VM while idle.
<img width="626" height="421" alt="Image" src="https://github.com/user-attachments/assets/a8134844-124d-40df-b09b-8c3579046cdf" />
Seems to be fixed now. Also, the "ChatGPT Work" tab was replaced with regular ChatGPT, so the feedback was well addressed.
Agree with @benjamindean comment, CPU has totally settled on 26.715.31925