Codex Windows 26.623.70822 consumes CPU continuously while idle in system tray and appears to trigger Defender activity

Open 💬 8 comments Opened Jun 30, 2026 by yLark

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

  1. Start the Codex Windows desktop application.
  2. Do not start any Codex task.
  3. Do not submit a prompt.
  4. Do not interact with the application.
  5. Minimize Codex to the Windows system tray.
  6. 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.exe
  • resources\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.

View original on GitHub ↗

8 Comments

tesiek · 8 days ago

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

k2-jeffd · 6 days ago

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

  • Codex Windows app: 26.707.9981.0
  • Executable initiating the file activity: ChatGPT.exe
  • Microsoft Defender platform/engine: 4.18.26060.3008
  • Real-time and behavior protection enabled

Finding

Across multiple ETL recordings, Defender repeatedly performs expensive real-time scans of Codex’s Sentry state file:

%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\
LocalCache\Roaming\Codex\web\Codex\sentry\scope_v3.json

The file is only approximately 34 KB. The scans are initiated by ChatGPT.exe and consistently report:

ScanType:  RealTimeScan
Reason:    OnClose
SkipReason: Not skipped

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.json accounted 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.json on Codex 26.707.41301, the same 26.707 release family:

https://github.com/openai/codex/issues/32496

A detailed analysis in that issue suggests the bundled @sentry/electron integration 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.json rewrites trigger expensive Defender OnClose scans 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.exe load while Codex is running.

Potential mitigations in the application would be:

  • Avoid rewriting scope_v3.json when its serialized content has not changed.
  • Debounce or substantially lengthen the Sentry scope persistence interval.
  • Reduce breadcrumb-driven full-scope persistence.
  • Review whether the Sentry minidump scope-persistence integration needs to remain active continuously on Windows.

I can provide the Defender ETL recordings privately if useful; they contain local process and filesystem metadata.

liangzhe2026 · 5 days ago

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

  • Codex Windows app: 26.707.9981.0
  • Windows 10 Pro 22H2, build 19045, x64
  • Intel Core i9-9900KS
  • 16 logical processors

Reproduction steps

  1. Create a brand-new Codex project.
  2. Do not create any conversations or tasks in that project.
  3. Select this empty project.
  4. Fully quit Codex and make sure the application processes exit.
  5. Start Codex again. It reopens with the empty project selected.
  6. Leave the application idle. At this point, Codex uses effectively no CPU.
  7. Switch to another existing project.
  8. CPU activity begins, even when no task is running.
  9. Switch back to the empty project.
  10. CPU activity continues and does not return to the original idle state.
  11. While the empty project is selected, fully quit Codex and start it again.
  12. CPU usage returns to effectively zero.

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:

  1. Switch to the empty project.
  2. Fully quit Codex.
  3. Start Codex again with the empty project still selected.

Simply switching back to the empty project without restarting does not stop the CPU activity.

benjamindean · 5 days ago

Same here. Working with the new ChatGPT app on a Windows laptop is very annoying now because the fan noise is constant.

ndilday · 5 days ago

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.

pgillett · 4 days ago

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" />

benjamindean · 1 day ago

Seems to be fixed now. Also, the "ChatGPT Work" tab was replaced with regular ChatGPT, so the feedback was well addressed.

pgillett · 1 day ago

Agree with @benjamindean comment, CPU has totally settled on 26.715.31925