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

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

• #28217

Powered by Codex Action

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._

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

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: https://github.com/openai/codex/discussions/29949#discussioncomment-17428007

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.

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.

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.

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.

Follow-up to my earlier AMD/RAPL data point above: this specific machine is now resolved, and the root cause turned out to be closer to the Windows Git-probing issues than to GPU rendering.

The important correction: the sustained idle CPU/package-power load was caused by Codex repeatedly launching Git root-discovery commands against a workspace path that contained an invalid/empty .git directory.

Representative command observed repeatedly:

git.exe -c core.hooksPath=NUL -c core.fsmonitor= rev-parse --show-toplevel

The affected path was a local Codex/workspace directory; I am intentionally omitting exact local paths and user-specific names. The .git directory had no valid repository metadata, and git rev-parse --show-toplevel failed for that workspace.

Mitigation that fixed this machine:

1. Rename the invalid empty .git directory aside as a backup.
2. Either remove it if the workspace does not need to look like a Git repo, or create a minimal valid Git repo if Codex/project state still expects that path to exist.
3. For the minimal-repo workaround, configure it to avoid scanning local artifacts:

git config core.untrackedCache true
git config status.showUntrackedFiles no

and add this to .git/info/exclude:

/*

After repairing the invalid .git, repeated git.exe launches stopped (git_count=0 during follow-up sampling), and the previously rising nonpaged-pool/file-cache signals flattened. So in this case the earlier RAPL/package-power symptom was downstream of a Codex Git root-discovery loop, not a pure Electron/GPU idle-rendering loop.

This seems directly related to #29911 and #29408. I still think there may be multiple Windows idle-power causes in this issue family, but for this machine the actionable trigger was: persisted workspace path + invalid/empty .git + repeated Git probing.

Final confirmation from my side: this is resolved locally after deleting an empty .git directory from the affected workspace.

Using Process Explorer, I observed git.exe being repeatedly spawned under Codex.exe while Codex Desktop was idle, with the PID changing continuously. I then identified the affected workspace as D:\test, which contained an empty .git directory.

After deleting D:\test\.git, the repeated git.exe launches stopped, and the fan noise / idle CPU symptom disappeared.

So my original report matches the invalid/empty .git + repeated Git root-discovery probing pattern described above. I’m fine with this issue being linked to or closed in favor of #29911 / #29408 if maintainers prefer, but the underlying behavior still seems worth fixing: an invalid .git directory should not cause high-frequency Git probing while the app is idle.

Follow-up with a minimal reproduction and confirmation.

I created a new empty directory:

D:\Code\CodexGitProbeTest

Then I opened it as a new Codex/ChatGPT Desktop project and sent this prompt:

This is a new empty project. Please create a README.md explaining that this is a Rust learning/practice project.

The app reported that it created README.md. After that, the directory contained:

.agents
.git
README.md

Both .agents and .git were empty directories.

At that point, the original symptom immediately returned: git.exe was repeatedly spawned under the Codex/ChatGPT Desktop process while the app was idle, with the git.exe PID changing continuously. The fan noise increased again.

After deleting the empty .git directory, git.exe stopped appearing repeatedly, and the fan noise quickly decreased and returned to normal.

So this is now reproducible from a new empty workspace. The issue does not appear to be only about a pre-existing broken Git repository. In this case, the app appears to create an empty/invalid .git directory itself during new project/workspace initialization, and then its own Git root-discovery probing loop is triggered by that invalid Git metadata.

This seems to have two parts:

• new workspace/project initialization creates an empty .git directory instead of either creating a valid Git repository or not creating .git at all
• Git root-discovery failure is retried too aggressively while idle, causing repeated git.exe process creation and idle CPU/power/fan noise

Deleting the empty .git directory is an effective local workaround, but the underlying behavior still seems like a Codex/ChatGPT Desktop bug.

Additional confirmation: I narrowed down the trigger further.

Using a new empty workspace, I tested two different interaction paths:

D:\Code\CodexGitProbeTest

Text-only interaction

If I open the empty workspace and only have normal text conversations with Codex/ChatGPT Desktop, without asking it to modify local files, no .git directory is created. I tested this across several rounds of conversation, and the repeated git.exe spawning does not occur.

Local file modification

If I then ask Codex/ChatGPT Desktop to write code or create/save a file in the workspace, the workspace immediately ends up with an empty .git directory.

For example, after asking it to write code and save it to a file, the directory contains:

.agents
.git
<created file>

Both .agents and .git are empty directories.

Once the empty .git directory appears, git.exe starts being repeatedly spawned under the Codex/ChatGPT Desktop process while the app is idle. The git.exe PID changes continuously, and the fan noise / idle CPU symptom returns.

After deleting the empty .git directory, the repeated git.exe launches stop and the fan noise quickly returns to normal.

So the more precise trigger appears to be:

new empty workspace
→ text-only chat: no `.git`, no issue
→ local file modification: empty `.git` is created
→ Git root-discovery probing repeatedly fails against invalid Git metadata
→ repeated short-lived `git.exe` processes
→ idle CPU/power/fan noise

This suggests the bug is specifically tied to the local file modification / file apply workflow, not merely opening a workspace or having a normal conversation.

It looks like the app may be creating an empty .git directory during its file-edit/project-state initialization path. If the app intends to initialize Git state, it should create a valid Git repository. If it does not intend to initialize Git, it should not create .git at all. In either case, repeated Git root-discovery failures against an invalid .git directory should probably be cached, backed off, or surfaced as an error instead of causing high-frequency git.exe process creation while idle.

------

User impact

I want to clarify that this is not merely an unexpected .git directory being created.

I first noticed the problem about three weeks ago because my laptop fan was running aggressively and the machine became noticeably hot. At that time, I could not identify the cause or find a workaround, so Codex was effectively unusable for me during those three weeks.

After repeated testing, I finally found the causal relationship:

1. In a non-Git directory, text-only conversations do not create .git.
2. As soon as Codex modifies or creates a local file, it silently creates .git.
3. Git processes then remain active, causing sustained resource usage, significant heat, and aggressive fan activity.
4. Deleting the generated .git directory immediately stops the Git activity, and the laptop quickly cools down.
5. If Codex modifies another file, .git is created again and the problem returns.

Therefore, the practical impact is not cosmetic or limited to an unexpected hidden directory. It makes the core file-editing functionality of Codex unusable on my machine.

Because the automatically created .git directory is not an obvious cause of laptop overheating, diagnosing this behavior took me approximately three weeks.