Windows Codex app repeatedly spawns git.exe/conhost.exe in Git workspaces, possibly contributing to Nonpaged Pool growth

Adding another current Windows repro with retained git.exe processes and multi-GB private memory growth.

Environment

• OS: Windows 11 Pro, version 10.0.26100, 64-bit
• Codex Desktop package: OpenAI.Codex_26.611.8604.0_x64__2p2nqsd0c76g0
• Codex main process path observed: C:\Program Files\WindowsApps\OpenAI.Codex_26.611.8604.0_x64__2p2nqsd0c76g0\app\Codex.exe
• Git: git version 2.54.0.windows.1
• Workspace: Windows-native Git repo under a Dropbox-synced folder
• Dropbox mitigation already applied: .git has Dropbox ignore ADS set (com.dropbox.ignored=1)

What I observed

After ruling out other major sources of memory pressure, Codex Desktop still appears to be the parent of heavy Git process churn in this workspace.

A high-resolution parent-PID snapshot trace over 90 seconds observed:

New git.exe starts: 1,149
Direct children of Codex.exe: 833
Child git.exe spawned by those Git calls: 316

This trace used process parent snapshots only, not command-line capture.

During/after the trace, live git.exe processes climbed to:

git.exe count: 125
Private memory: ~4.2 GB
Working set: ~1.3 GB

Killing the pile with:

Stop-Process -Name git -Force -ErrorAction SilentlyContinue

reset the count to zero, but the accumulation returned while the Codex Desktop project thread stayed open/active.

A later baseline, after cleanup and continued Codex use, again shows retained Git processes:

git.exe count: 31
Private memory: ~1.02 GB
Working set: ~0.19 GB

Manual git status --short for the repo completed quickly (~45 ms), so ordinary Git status cost does not explain the number of retained processes by itself.

Things ruled out in this case

• Docker Desktop / Rancher / WSL distros were stopped during the repro.
• Hyper-V hidden allocation was not active.
• Acronis/Cyber Protect had previously caused separate kernel-pool and commit pressure, but was uninstalled. After uninstall, kernel pools normalized and Acronis services/drivers were gone.
• Dropbox was not the parent of the git.exe processes; parent attribution pointed to Codex.exe.

Impact

This can consume multiple GB of private memory just from retained git.exe processes and makes a high-end Windows machine feel sluggish over time. It also complicates troubleshooting because the symptoms look like broad system memory pressure until the process tree is inspected.

Expected behavior

Codex Desktop should bound/debounce Git polling and ensure spawned Git child processes are reaped. It would also help to expose a per-workspace setting to disable or reduce background Git status/snapshot polling, especially for synced folders or large/dirty repos.

Workaround

For now, using a projectless/non-repo thread for system diagnostics avoids triggering repo Git polling, and killing accumulated git.exe processes temporarily restores memory. Ignoring .git in Dropbox helps reduce sync churn but does not stop Codex from rebuilding the process pile.

Adding a Windows repro/analysis pass with a tested candidate patch sketch. I am not opening a PR unless a maintainer explicitly asks for one, per docs/contributing.md.

Environment

• OS: Windows 11 Pro 10.0.26200
• Codex Desktop package observed in command line: OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0
• Git: 2.54.0.windows.1
• Upstream source inspected: 63f009e9dad2e70454b7ed6434d8aa28dfb52b51

Process churn measurements

I used a local PowerShell measurement script that:

• tries CIM process-start events when possible,
• falls back to polling without admin rights,
• can filter to processes with Codex.exe / codex.exe ancestry,
• redacts common token/key patterns from command samples.

Non-admin polling caveat: this likely undercounts very short-lived processes. CIM process-start events were denied in my non-admin shell with 0x80041003, and WPR failed without elevation with 0xc5585011.

Observed while Codex Desktop was active:

| Scope | Duration | git.exe | conhost.exe | powershell.exe | Notes |
|---|---:|---:|---:|---:|---|
| all matching processes | 20s | 21 starts, 63/min | 43 starts, 129/min | 23 starts, 69/min | includes non-Codex machine activity |
| Codex descendants only | 15s | 24 starts, 96/min | 29 starts, 116/min | 14 starts, 56/min | parent-chain filtered to Codex.exe / codex.exe |
| Codex descendants only | 30s | 30 starts, 60/min | 51 starts, 102/min | 28 starts, 56/min | measured during attempted WPR run |

The descendant-filtered runs are the most relevant. Even with polling undercounting, I still see steady git.exe and conhost.exe churn under the Codex process tree.

Source path that looks like an amplifier

Two open-source paths still fan out one Git process per untracked file:

• codex-rs/tui/src/get_git_diff.rs
• get_git_diff runs git ls-files --others --exclude-standard, then runs git diff --no-index ... once per untracked file.
• codex-rs/git-utils/src/info.rs
• diff_against_sha does the same.
• This is exposed through app-server as gitDiffToRemote via codex-rs/app-server/src/request_processors/git_processor.rs.

Hypothesis: if Desktop/app-server refreshes Git diff state periodically or on workspace events, a workspace with many untracked files can amplify one refresh into many short-lived git.exe launches. On Windows those launches also produce conhost.exe churn, which matches the symptoms in this issue.

Candidate patch sketch tested locally

I prepared a local patch, but have not opened a PR:

• cap detailed untracked-file diffs at 32 files;
• preserve existing behavior under the cap;
• append an explicit omission note for additional untracked files;
• add regression tests that assert the detailed diff subprocess count is bounded.

Focused tests passed locally:

cargo test -p codex-tui get_git_diff::tests::                 -> 6 passed
cargo test -p codex-core test_get_git_working_tree_state       -> 5 passed
cargo test -p codex-git-utils                                  -> 22 passed
git diff --check                                               -> clean

This does not prove that the private Desktop UI is calling gitDiffToRemote at the problematic frequency, but it verifies that one plausible OSS amplification path can be bounded without breaking the existing focused tests.

If this mitigation direction aligns with the team's intended architecture, I can turn the local patch into a focused PR after an explicit maintainer invitation.

---

Adding one smaller Windows-specific candidate in addition to the bounded-untracked-diff sketch above.

Current source path:

• codex-rs/git-utils/src/info.rs::run_git_command_with_timeout_from
• This is the shared runner for internal Git commands in codex-git-utils.
• On Windows, tokio::process::Command exposes creation_flags.

Local candidate patch:

#[cfg(windows)]
const CREATE_NO_WINDOW: u32 = 0x0800_0000;

// ...

let mut command = Command::new(git);
#[cfg(windows)]
command.creation_flags(CREATE_NO_WINDOW);

Why this is narrower than changing the generic shell/tool spawn path:

• It applies only to Codex internal Git commands.
• It does not change user shell tool execution.
• It does not affect inherited stdio/interactive process semantics.
• It is Windows-only via #[cfg(windows)].

Local validation against origin/main f774455c3a831dfab2c6f37a1f624b8097f6f2c2:

• cargo test -p codex-git-utils -> 22 passed
• cargo fmt --check -> passed; stable rustfmt emitted repo-config warnings that imports_granularity is nightly-only
• git diff --check -> passed

Boundary:

• This should help the visible-console part of Git subprocess launches by requesting CREATE_NO_WINDOW.
• It does not by itself reduce the number of Git launches; the bounded-untracked-diff/single-flight/debounce work is still needed for process count and retained-process pressure.
• I have not proven the packaged Desktop runtime symptom disappears with this patch because that needs a GUI-parent Desktop trace.

As before, I will not open a PR without an explicit maintainer invitation.

Have same issue. Codex spawns a large number of git.exe every few seconds. Even though they close immediately, it causes windows pool memory to grow over time and after about 12 hrs system is sluggish/non responsive. No other way to recover apart from rebooting. Do not have this problem if I do not run codex.
Version 26.623.42026 • Released Jun 26, 2026

This bug is back again today ...

Adding another Windows Desktop data point. My visible symptom is repeated short-lived powershell.exe / conhost.exe flashes from Codex Desktop. This looks related to the same Windows child-process churn class discussed here, even though in my trace the clearest repro was the shell snapshot/probe path rather than retained git.exe processes.

Environment

• OS: Windows 11 Pro 10.0.26200, 64-bit
• Machine: HP EliteBook 865 16 inch G10 Notebook PC
• CPU: AMD Ryzen 7 PRO 7840U w/ Radeon 780M Graphics, 8 cores / 16 logical processors
• RAM: ~56 GB
• Codex Desktop package: OpenAI.Codex_26.623.19656.0_x64__2p2nqsd0c76g0
• Codex Desktop process path observed: C:\Program Files\WindowsApps\OpenAI.Codex_26.623.19656.0_x64__2p2nqsd0c76g0\app\Codex.exe
• Codex CLI: codex-cli 0.142.5
• Git: git version 2.47.1.windows.1
• PowerShell: 7.6.0

What I observed

With Codex Desktop open, I saw repeated visible black console flashes. A non-admin polling trace captured short-lived child processes parented by the Codex Desktop app, with matching transient conhost.exe processes.

The repeated command shape was:

powershell.exe -NoProfile -NonInteractive -Command "$ErrorActionPreference = 'Stop'; $cpuByPid = @{}; Get-CimInstance Win32_PerfFormattedData_PerfProc_Process ... Get-CimInstance Win32_Process ... ConvertTo-Json"

That process was parented by:

C:\Program Files\WindowsApps\OpenAI.Codex_26.623.19656.0_x64__2p2nqsd0c76g0\app\Codex.exe

Each probe could create a visible conhost.exe, which is what caused the annoying cmd/terminal flash.

I first disabled a BrowserOS MCP server to rule out MCP startup/process churn. The flashes still happened, so that was not the cause in this case.

Repro steps

1. Use Codex Desktop on Windows with the shell tool enabled.
2. Leave the default shell_snapshot feature enabled.
3. Open/use an active Desktop thread/workspace.
4. Observe repeated short-lived PowerShell/conhost launches and visible console flashes.
5. Disable shell_snapshot, fully quit and reopen Codex Desktop.
6. The flashes stop.

Current workaround

This stopped the visible flashes for me:

codex features disable shell_snapshot

Then fully quit and reopen Codex Desktop.

After the workaround, my feature state is:

hooks           stable  true
shell_snapshot  stable  false
shell_tool      stable  true

So this does not disable shell tool usage. It only disables the shell snapshot feature. The likely tradeoff is worse repeated shell startup/snapshot performance, but the Desktop console flashing stopped.

Expected behavior

Codex Desktop should not spawn visible Windows console windows for background probes/snapshots. If these child processes are needed, they should be launched hidden/no-window on Windows, and high-frequency Git/shell polling should be bounded/debounced separately.

Severity escalation: 554 Git starts in 20 seconds, and current Desktop still has no true Review-off mode

A controlled Windows Win32_ProcessStartTrace capture during Codex task switching recorded:

• 554 git.exe starts in 20 seconds
• bursts of 40–58 starts per second
• one Codex PID was the direct parent of 277 top-level starts
• surviving/stuck commands included rev-parse, remote -v, config core.fsmonitor, and status --porcelain

User impact was not a cosmetic Task Manager spike: mouse input and the whole desktop stalled. This reproduced on a high-end workstation with ordinary development repositories; it is not reasonably explained by weak hardware or an enormous monorepo.

The strongest A/B was repository scope:

• Git-backed saved task roots: process storm and pointer stalls
• tasks migrated to a non-Git control root while real repositories remained accessible by explicit path: a follow-up 10-second trace recorded zero Git starts and zero live Git processes

That containment required migrating 68 saved tasks away from their real Git roots. A user should never have to break the app's natural project/workspace association just to keep the machine responsive.

The original storm was captured on Desktop 26.707.3748.0. Read-only inspection of the current 26.707.8479.0 production bundle shows the Git Review setting schema still accepts only:

full
last-turn-only

There is still no off. Last Turn Only is not off. It does not satisfy users who need Codex to stop passive Review/index/status work while retaining normal shell access to Git when they explicitly request it.

Required action:

1. Add a real, supported Git Review Off mode.
2. No Git write/index mutation on passive thread/project navigation.
3. Debounce, coalesce, cache, and cancel superseded probes by normalized repository root.
4. Bound Git worker concurrency and kill timed-out children by exact ownership.
5. Keep all Review work off the UI-critical path.
6. Add Windows regression coverage that fails on process-start rate, not merely final process count.

This has persisted across multiple releases and can make a top-tier workstation feel unusable. It needs a product fix, not another user-side cleanup workaround.

Adding a current Windows Desktop repro with an exact snapshot cadence and a controlled dirty/clean A/B.

Environment

• Windows 11 Pro, build 26200
• Codex Desktop package: OpenAI.Codex_26.707.12708.0_x64
• Git: 2.40.1.windows.1
• Git-backed workspace: 21,817 tracked paths
• No broad Defender exclusion was used

Repeated snapshot path

While the Git-backed task remains open and no user Git action is requested, the app repeatedly launches the same temporary-index snapshot path at approximately 2.1-second intervals:

git -c core.hooksPath=NUL -c core.fsmonitor= add -u
git -c core.hooksPath=NUL -c core.fsmonitor= write-tree

The cadence is especially damaging when one snapshot takes nearly the entire interval.

Controlled A/B

Before cleanup, the root had 519 tracked status entries and 3,809 non-ignored untracked files. A copied-index add -u plus write-tree snapshot had a median runtime of approximately 2,041 ms.

All changes were first captured on local recovery refs. After restoring the root to a clean state, the same copied-index path produced:

249.8 ms
184.9 ms
187.5 ms
200.4 ms
202.3 ms

Median: 200.4 ms, about a 10x improvement. A separate clean worktree measured approximately 148 ms.

Repository cleanup therefore greatly reduces per-snapshot cost, but it does not address the unconditional cadence or Windows child-process churn. Sparse worktrees should improve cost further, but they are not a substitute for scheduling control.

Current control surface

Read-only inspection of this installed bundle shows:

• git-review-mode accepts only full and last-turn-only;
• the UI labels the latter “Disable Git-Based Review” and says it disables Unstaged/Staged/Branch sources to avoid Git operations;
• there is still no true off, on-turn, or manual mode;
• the internal ghost_snapshot config structure exposes only large-untracked-file/directory and warning controls, not an enabled/disabled switch.

Requested mitigation

Please add a supported per-workspace Git snapshot policy:

• automatic
• on-turn / event-driven
• manual
• off

For on-turn, a safe baseline could be captured at task start or immediately before the first mutating action, then refreshed at turn completion, diff/review, undo, or an explicit user/agent request. Passive project navigation should not continuously run add -u and write-tree.

Independently, snapshots should be single-flight, debounced, cancellable when superseded, and coalesced by normalized worktree root.