Codex Windows App keeps spawning `git.exe status --porcelain=v1 -z` and leaves orphan `git.exe` / `conhost.exe` processes

[xiaoye-520]

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

26.325.3894.0

What subscription do you have?

On Windows, the Codex Windows App repeatedly spawns Git processes such as: - git.exe status --porcelain=v1 -z and also creates matching console host processes such as: - \??\C:\WINDOWS\system32\conhost.exe 0x4 After closing the Codex window, new processes stop appearing, but many existing git.exe / conhost.exe processes remain alive. Even after ending Codex.exe from Task Manager, the leftover Git-related processes are still present. This looks like the app is polling Git state very aggressively and not cleaning up child processes correctly on exit.

What platform is your computer?

No response

What issue are you seeing?

C:\Users\root\Documents\New project\ is the default project directory used by Codex.

What steps can reproduce the bug?

1. Open Codex Windows App.
2. Open a Git repository.
3. Observe Task Manager / Process Explorer.
4. Notice repeated creation of:
   • git.exe status --porcelain=v1 -z
   • conhost.exe 0x4
5. Close the Codex app window.
6. New Git processes stop appearing, but many previously created git.exe / conhost.exe processes remain.
7. End Codex.exe manually in Task Manager.
8. Leftover git.exe / conhost.exe processes are still not cleaned up.

What is the expected behavior?

No response

Additional information

No response

[github-actions]

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

• Windows app repeatedly spawns \git ls-files --others --exclude-standard -z; ntfs.sys NtFC nonpaged pool grows continuously #16786
• High CPU usage when idle: background git/subprocess churn in Codex (Electron/Node) even when UI is inactive #15620
• Codex Desktop app spawns Git on launch in read-only mode and leaves massive tmp_pack_/tmp_obj_ garbage in .git/objects on macOS #16820

Powered by Codex Action

[msg7086]

Same, I'm seeing git process being called multiple times per second hogging resources. Windows 10.

In my case it also calls git add -A, git add -u, git write-tree, git add -- files files... and git rev-parse. NON STOP.

[badwordsno]

I hit what looks like the same Windows Codex git/conhost churn issue, but with RAMMap evidence of kernel memory fallout.

RAMMap snapshot after the event:

• Page Table: 6.636 GiB
• Driver Locked: 0.375 GiB
• ProcessList entries in the .RMP snapshot: 210,410
• git.exe entries: 138,169
• conhost.exe entries: 69,607
• Current live git.exe count after the event: 0
• Current live conhost.exe count after the event: 4

So the active process churn had already stopped, but RAM stayed around 24-25 GiB used because the Page Table bucket remained huge. This caused severe system/game freezing symptoms after FH6 launch, with GPU usage dropping to single digits.

This seems more severe than normal CPU churn because the aftermath persists even after git.exe/conhost.exe are gone.

[yuzhiyang1]

Adding a source-level datapoint and a proposed mitigation branch from a Windows/HDD reproduction.

Observed user impact:

• Codex Desktop/CLI work against a large repository can drive disk usage to 100% on a mechanical HDD.
• On older disks this can make the whole machine appear frozen, not just Codex.
• The suspicious process activity is repeated Git metadata collection, especially git status --porcelain-style worktree scans.

Source-level finding:

• codex-rs/core/src/turn_metadata.rs collects WorkspaceGitMetadata for turns.
• That path currently includes get_has_changes(cwd).
• get_has_changes is implemented in codex-rs/git-utils/src/info.rs using git status --porcelain.
• For large worktrees, and especially when run on an HDD, this can scan many small files and saturate disk I/O.
• This metadata is useful, but it is not important enough to block a turn or make the app keep hammering the disk.

Proposed mitigation:

I prepared a branch that keeps commit hash and remote URL metadata, but makes only the has_changes signal best-effort with a short timeout. If git status does not return quickly, turn metadata simply omits has_changes instead of continuing to wait on a full worktree scan.

Branch:
https://github.com/yuzhiyang1/codex/tree/codex/throttle-git-metadata-on-hdd

Compare:
https://github.com/openai/codex/compare/main...yuzhiyang1:codex:codex/throttle-git-metadata-on-hdd?expand=1

Testing performed locally:

• cargo check -p codex-core --tests
• just test -p codex-core turn_metadata_state_omits_has_changes_when_status_budget_expires
• cargo fmt -p codex-core --check
• just fix -p codex-core

Note: I tried to open a PR from the fork, but GitHub returned GraphQL: yuzhiyang1 does not have the correct permissions to execute CreatePullRequest, so I am leaving the branch here for maintainers to inspect or cherry-pick.

[YooKyubin]

I am seeing what appears to be the same class of issue on Windows with the Codex desktop app.

In my case, opening or keeping a Git repository session active causes git.exe and conhost.exe to be spawned thousands of times per minute. ProcMon shows repeated git status --porcelain=v1 -z, rev-parse, remote, add -u, and write-tree commands with CODEX_SHELL=1. Some commands use a temporary Codex Git index via GIT_INDEX_FILE=<temp>\codex-index-...\index.

The additional impact I observed is Windows Nonpaged Pool growth, with PoolMon growth in tags such as Proc, MiP2, PsIn, and EtwS.

I filed a more detailed report here: #26812

[null0526]

I can reproduce a very similar issue on Windows after restarting Codex Desktop.

Environment

• OS: Windows
• Codex Desktop version: 26.609.41114
• Workspace: Git repository at D:\ProjTerra
• Repository state: one normal Git worktree only
• No active Python test/runner was running when the screenshots were taken

What I observe

After restarting Codex Desktop, the problem is still reproducible.

When the main Codex thread is focused, Task Manager shows roughly:

• Codex (22)
• Codex CPU: about 1.0%
• Memory: about 841 MB
• System CPU: about 16%

When I switch away from that main thread / the thread is unfocused, Task Manager expands to roughly:

• Codex (215) or previously Codex (269)
• Codex group CPU: about 20-25%
• System CPU: about 62-83%
• Memory: about 1.0-1.46 GB
• Many child processes appear, especially:
  • Git for Windows
  • conhost.exe
  • node_repl.exe
  • PowerShell / pwsh
  • multiple Codex helper/renderer processes

When I focus the main thread again, the process tree shrinks back to a much smaller number of child processes and CPU drops.

This makes the issue look less like normal UI rendering cost and more like background workspace/thread/runtime restoration triggering a burst of Git/process polling.

Evidence from local checks

I captured one of the Git commands being spawned:

git.exe -c core.hooksPath=NUL -c core.fsmonitor=false status --porcelain
Local checks from the repository:
C:\Users\ml292.codex\worktrees
is empty.
git worktree list --porcelain
shows only one worktree:
worktree D:/ProjTerra
branch refs/heads/codex/projterra-restructure-lab
A single Git status call is not extremely slow:
git -c core.hooksPath=NUL -c core.fsmonitor=false status --porcelain
elapsed: about 178 ms
So the high CPU does not appear to be caused by one slow Git command. It looks more like Codex Desktop repeatedly or concurrently spawning many Git status checks and console host processes.
I also closed the only visible pending subagent record before restarting Codex. After a full Codex Desktop restart, the issue still reproduced, so this does not look like a stale project task or leftover test runner.
Expected behavior
Codex Desktop should not spawn hundreds of Git/console/runtime child processes just because the user switches focus or changes thread context.
Workspace status polling should be throttled, deduplicated, cancellable, and child processes should be cleaned up promptly.
Actual behavior
Switching focus/thread context appears to trigger a large burst of Git/status/runtime process creation. This causes high CPU and makes the app difficult to use for long-running projects.
Why this may be related to this issue
This appears to match the issue description here: repeated Git status polling and many Git/conhost child processes on Windows.
The additional detail in my case is that the process explosion is strongly correlated with focus/thread switching:
focused main thread: Codex (22), low CPU
unfocused/switched thread: Codex (215+), high CPU
refocus main thread: process count drops again
I can provide screenshots showing both states.