Windows 11: Codex 26.616.4196.0 causes sustained fan noise and GPU/CPU activity while idle

[manxisuo]

What version of the Codex App are you using (From “About Codex” dialog)?

26.616.41845

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

What happened?

After updating Codex on Windows 11, the app appears to cause sustained fan noise and noticeable heating even when idle.

If I fully quit Codex, the laptop becomes quiet again within a short time. When I reopen Codex, the fan noise comes back even if no task is running.

Environment

• OS: Windows 11
• Device: Lenovo laptop
• GPU: Intel Iris Xe Graphics
• Codex version: 26.616.4196.0
• Previous package version seen in logs: 26.616.3767.0
• Update/install time observed: 2026-06-19 around 22:55-23:39

Diagnostics

While Codex is open:

• Codex main / renderer / GPU processes show ongoing CPU activity.
• Codex GPU process shows Intel Iris Xe 3D engine activity around 6% - 11%.
• Total Codex memory usage is around 1.1 GB.
• The issue reproduces even when Codex is idle.

Other likely causes were checked:

• Visual Studio Installer had completed and was not the cause.
• Disk I/O was not abnormal.
• Microsoft Defender was not actively scanning.
• Explorer CPU usage normalized after restarting Explorer.
• Fan noise stops shortly after quitting Codex.

Expected behavior

When Codex is open but idle, CPU/GPU usage should remain low and should not cause sustained fan noise or heating.

Suspected cause

This may be a performance regression in Codex 26.616.4196.0, possibly related to WebView/GPU rendering on Windows 11 with Intel Iris Xe Graphics.

Additional notes

A clean A/B check strongly points to Codex:

1. Quit Codex → laptop becomes quiet soon after.
2. Reopen Codex → fan noise returns even without running a task.

I saw similar high-CPU reports for macOS involving syspolicyd / trustd, but this issue appears different: it reproduces on Windows 11 with Intel Iris Xe Graphics, and the observed activity is from Codex renderer / GPU processes rather than macOS security assessment.

What steps can reproduce the bug?

1. Use a Windows 11 laptop with Intel Iris Xe Graphics.
2. Install or update Codex to version 26.616.4196.0.
3. Launch the Codex desktop app.
4. Do not start any task. Leave Codex open and idle for several minutes.
5. Observe that the laptop fan starts spinning loudly and the machine becomes noticeably warm.
6. Quit Codex completely.
7. Observe that the fan noise drops and the laptop becomes quiet shortly after.
8. Reopen Codex and leave it idle again.
9. Observe that the fan noise returns.

What is the expected behavior?

When Codex is open but idle, it should use minimal CPU/GPU resources and should not cause sustained fan noise or noticeable heating.

Quitting and reopening Codex should not change the laptop's thermal behavior unless an actual task is running.

Additional information

This appears to be specific to the Codex desktop app after the recent update.

I checked other likely causes:

• Visual Studio Installer had completed and was not the cause.
• Disk I/O was not abnormal.
• Microsoft Defender was not actively scanning.
• Explorer CPU usage normalized after restarting Explorer.
• Quitting Codex makes the laptop quiet again shortly afterward.

Observed diagnostics while Codex was open:

• Codex renderer / main / GPU processes showed ongoing CPU activity.
• Codex GPU process showed Intel Iris Xe 3D engine activity around 6% - 11%.
• Total Codex memory usage was around 1.1 GB.

I saw similar high-CPU reports for macOS involving syspolicyd / trustd, but this appears different because this reproduces on Windows 11 with Intel Iris Xe Graphics.

[github-actions]

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

• Codex Desktop shows elevated renderer/GPU-process activity on macOS #28217

Powered by Codex Action

[Necmttn]

Idle resource regressions need daemon health samples. Every N seconds while idle, record active threads, pending tool calls, app-server requests, renderer/GPU activity class, CPU, RSS, and last user event age. If no work is active, the UI can show which loop is keeping GPU/CPU awake instead of making fan noise the only signal.

---

Generated with ax.

[mkuma443]

I can reproduce this on Codex for Windows 26.616.6631.0.

Environment:

• Windows 11
• 16 logical processors
• Pets are asleep
• Audio is disabled
• No active Codex task

Measured over 15 seconds:

• Window visible and idle: approximately 1.6% total system CPU
  (about 25% of one logical core)
• Window minimized and idle: approximately 0.16% total system CPU
• Reduction after minimizing: approximately 90%

While visible, most activity came from:

• Codex.exe --type=gpu-process
• Codex.exe --type=renderer

The backend, node_repl processes, and antivirus processes were essentially idle during the measurement.

The large difference between visible and minimized states strongly suggests continuous rendering, repainting, or animation while the window is visible.

Feedback ID: 019ef1c5-2616-7411-be90-af586a06bd5a

[Yassycodes]

Thanks for writing this up. I am seeing a related Windows Codex Desktop performance regression in #28855: since June 12, opening/using Codex Desktop can cause severe intermittent mouse/typing/system input lag, and it still persists for me on OpenAI.Codex 26.616.10790.0.

I linked your report in a broader Discussion collecting recent Windows Desktop performance reports here: #29949 (comment)

No action needed from you unless you want to add more detail there, but I wanted to connect the reports because the recent Windows issues look related enough that they may need a canonical tracker.

[manxisuo]

Update: this is still reproducible on my machine.

Current Codex version: 26.616.81150
OS: Windows 11
Device/GPU: Lenovo laptop, Intel Iris Xe Graphics

When Codex is open and idle, I still observe sustained CPU/GPU activity and fan noise. After fully quitting Codex, the fan noise drops shortly afterward.

I can provide additional diagnostics/logs if helpful.

[manxisuo]

Update after two Codex updates:

This still reproduces on OpenAI.Codex 26.623.5546.0.

I have also disabled Playwright/Figma/Notion/Visio MCPs and checked Microsoft PC Manager processes/services. The issue still remains.

Current observation:

• Opening Codex causes the laptop fan to spin loudly and temperature to rise.
• Closing Codex makes the machine quiet again.
• Recent process sampling still shows Codex-related activity, including Codex.exe main/GPU/renderer processes and codex.exe app-server.

So this no longer appears to be caused by Playwright MCP or Microsoft PC Manager.

[keydango27-maker]

Additional Windows/AMD data point: this still reproduces for me on a newer Codex Desktop build.

Environment:

• Codex Desktop: OpenAI.Codex 26.623.8305.0
• OS: Windows 11
• CPU/GPU: AMD Ryzen 7 255 w/ Radeon 780M Graphics, 8 cores / 16 logical processors
• GPU driver: AMD Radeon 780M, 32.0.23033.1002

Current observation with Codex open and no active task running:

• AMD RAPL package power sampled for 20 seconds: avg 16.655 W, min 15.630 W, max 19.165 W
• Windows CPU utility during the same sample: avg 10.3%
• CPU time delta is concentrated in the main Electron shell process:
  • main Codex.exe: 2.062 s CPU over 20 seconds, about 10.31% of one logical core
  • codex.exe app-server: 0.078 s CPU over 20 seconds, about 0.39% of one logical core
  • renderer/GPU/utility helpers were near zero in this sample

Earlier controlled checks on the same machine found the same pattern:

• fully quitting Codex drops idle package power to roughly 5 W
• suspending only the main Electron shell process dropped package power to roughly 6 W, while leaving the app-server itself mostly idle
• that suspend workaround is not usable operationally because it breaks/risks Codex mobile remote-control behavior
• launch flag tests did not help here: normal launch averaged 15.79 W; --disable-direct-composition averaged 15.94 W; --disable-gpu-compositing --disable-direct-composition averaged 16.48 W

This makes the issue look less like active agent/model work and more like persistent main desktop shell/runtime activity while idle. The important bit in my case is that it persists after several recent updates, including 26.623.8305.0, and is directly visible through AMD RAPL package power rather than only fan noise.