Windows: Codex spawns many Git for Windows processes causing sustained high CPU after recent update

What happened?

After updating Codex to the latest Windows version, my development machine becomes very slow. In Windows Task Manager, CPU is continuously consumed by multiple Git for Windows processes while Codex is open during development.

I manage version control manually and did not explicitly ask Codex to run any Git operation. The Git processes appear to be spawned repeatedly by Codex or by its integration while working in a local project.

Impact

Windows 11 becomes noticeably laggy during development.
CPU remains high for a long time.
Multiple Git for Windows / git.exe processes are visible in Task Manager.
This makes the current Windows Codex workflow difficult to use.

Environment

OS: Windows 11
Git: Git for Windows
Codex: latest Windows version available at the time of reporting
Shell/IDE: Windows development environment; also considering PowerShell CLI because WSL is not available on this machine

Screenshot / observation

Task Manager shows multiple Git for Windows processes, each consuming CPU, while Codex is running.

Expected behavior

Codex should not continuously spawn Git processes or keep Git CPU usage high when idle or during normal development. Ideally there should also be a setting to disable Codex Git integration, since some users manage Git manually.

Actual behavior

After the recent update, Codex appears to repeatedly invoke Git, causing sustained CPU usage and system lag.

Request

Could you please check whether the recent Windows build introduced a Git polling / metadata loop? Also, is there any supported configuration to disable Git integration or reduce Git polling frequency in Codex on Windows?

Potentially related reports:

Windows desktop app repeatedly spawning git.exe / git add -A / git rev-parse
Windows app repeatedly running Git commands at high frequency
Git metadata retry loop in non-standard or non-Git workspaces

I can provide more details if needed, such as process tree, exact Codex version, workspace layout, or logs.

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

Codex Windows App keeps spawning about 1000 git command per minute NON STOP #20567
Codex Desktop 26.506.31421 main Electron process pegs ~280% CPU on macOS while app-server is idle #22053

Powered by Codex Action

I have the same issue.

I have the same issue.

I’m using Codex in JetBrains now.

I have the same issue.

Besides, the change detection structure of Git is also incorrect

I have the same issue. The problem started occurring since the upgrade to version 26.506.31421 on May 9. Codex will continuously invoke the Git for Windows process to operate on the project repository, and there is no problem when switching to a new chat without a Git project.

I have the same issue.

Same here. It spawns Git for Windows once you click into a git managed project. And it get worse when you click multiple projects.

Same problem here.

A temporary alternative is to use Codex without a .git folder in your project. This can be done by copying the project to another folder without the .git or simply renaming the .git folder to something like .git_ or .git_bak.

If you need to keep Git active in your directory, another workaround is using a PowerShell script (.ps1) like the one I created.

If you prefer, you can ask an AI to generate a similar script for you, but I am sharing mine below in case it helps. It monitors the system and terminates the Git process whenever it is spawned by Codex.exe. I also created a batch file (.bat) for an easy startup.

For this to work, both files must be saved in the same folder. Whenever you use Codex, just run the .bat launcher as an Administrator.

Note: This workaround can cause a few side effects that I'm still trying to find a solution for. For instance, it prevents modified files from showing up directly within the Codex IDE, meaning you'll need to keep another IDE (like VS Code) open alongside it to track your changes.

CodexBlocker.ps1

Write-Host "Codex Mitigation Monitor Active. Press Ctrl+C to terminate." -ForegroundColor Cyan

while ($true) {
    # Capture all active git.exe processes
    $gitProcesses = Get-CimInstance Win32_Process -Filter "Name = 'git.exe'"
    
    foreach ($proc in $gitProcesses) {
        # Find the parent process
        $parent = Get-CimInstance Win32_Process -Filter "ProcessId = $($proc.ParentProcessId)"
        
        # If the parent is Codex, terminate the subprocess
        if ($parent.Name -eq "Codex.exe") {
            Write-Host "[Blocked] git.exe (PID: $($proc.ProcessId)) spawned by Codex has been terminated." -ForegroundColor Yellow
            Stop-Process -Id $proc.ProcessId -Force -ErrorAction SilentlyContinue
        }
    }
    # Polling interval (300ms)
    Start-Sleep -Milliseconds 300
}

Launch-Blocker.bat

@echo off
cd /d "%~dp0"
powershell -NoProfile -ExecutionPolicy Bypass -File "CodexBlocker.ps1"
pause

Here is a preview of the script working in the background:

Same on mac

@azsama

@azsama Why did you close this issue?

I’m seeing what looks like the same Windows git.exe fan-out pattern, with one additional detail that may help narrow the trigger.

Environment:

Windows 11
Git for Windows
Codex Desktop: pre-update package visible in process command line was OpenAI.Codex_26.608.1337.0
Codex later updated during my test window; I can add the exact post-update version from About Codex if useful.

What I observed:

Codex spawned many git.exe processes under Codex.exe / codex.exe.
During the bad state, the distinctive command was:

git.exe -c core.hooksPath=NUL -c core.fsmonitor= hash-object --no-filters -- <path>
The workload looked like file-by-file hashing of generated artifacts, especially JSON/HTML/MD/CSV/email-style files under hot output folders.

Diagnostics I collected:

I wrote a PowerShell watchdog that logs every git.exe process with parent process, grandparent process, command line, classification, path count, and recent hash-object count.
In the pre-mitigation logs, the bad rows were repeated hash-object --no-filters -- <file> invocations against generated artifacts.
After mitigation and a later Codex update, a fresh storm-only monitor run from 2026-06-11T17:35:19 to 2026-06-11T18:07:14 logged:
- total git rows: 1582
- HashObjectRows: 0
- StormRows: 0
- WouldKillStorm: 0
- normal noise was mostly rev-parse, remote -v, status --porcelain, config core.fsmonitor, diff, ls-files, etc.

Mitigation that appears to have helped:

Moved future generated outputs into ignored scratch folders like _tmp/<workflow>/<run>/....
Added narrow .gitignore rules for historical hot generated folders and file types.
Updated local workflow/agent instructions so future runs do not create high-cardinality generated artifacts in Git-visible batch folders.
I also switched from a kill-all git.exe watchdog to a storm-only monitor so normal Codex Git probes are allowed and only hash-object fan-out is flagged.

My interpretation:

My repo hygiene likely amplified the issue by putting many generated artifacts in active workspaces.
But Codex probably still needs a product-side guardrail here: bounded/debounced/cached Git scans, cancellation, and avoiding per-file Git process storms over generated/ignored artifact directories.
It would also help to have a supported setting to disable or reduce Codex Git integration/polling on Windows.

Same comment posted on #20567

The solution is to filter path from git and PS (I have used Codex chat to analize the problem)
Agents will work well, may be some time need to say to use full path, when agent forget how to work.

Run normally for Codex updates.

Run with only git removed
pwsh -File Start-Codex-FilteredPath.ps1
Run with git and powershell removed
pwsh -File Start-Codex-FilteredPath.ps1 -RemovePowerShell

Powershell script copy in Start-Codex-FilteredPath.ps1

param(
    [switch]$RemovePowerShell,
    [switch]$DryRun
)

$ErrorActionPreference = 'Stop'

function Remove-PathEntries {
    param(
        [Parameter(Mandatory = $true)]
        [string]$PathValue,

        [Parameter(Mandatory = $true)]
        [scriptblock]$ShouldRemove
    )

    $entries = $PathValue -split ';' | Where-Object { $_ -ne '' }
    $kept = New-Object System.Collections.Generic.List[string]
    $removed = New-Object System.Collections.Generic.List[string]

    foreach ($entry in $entries) {
        if (& $ShouldRemove $entry) {
            $removed.Add($entry)
        }
        else {
            $kept.Add($entry)
        }
    }

    [pscustomobject]@{
        Path = ($kept -join ';')
        Removed = $removed
    }
}

function Find-CodexExe {
    $package = Get-AppxPackage -Name 'OpenAI.Codex' -ErrorAction SilentlyContinue |
        Sort-Object Version -Descending |
        Select-Object -First 1

    if ($package -and $package.InstallLocation) {
        $candidate = Join-Path $package.InstallLocation 'app\Codex.exe'
        if (Test-Path -LiteralPath $candidate) {
            return $candidate
        }
    }

    $packageRoot = 'C:\Program Files\WindowsApps'
    $matches = Get-ChildItem -LiteralPath $packageRoot -Directory -Filter 'OpenAI.Codex_*_x64__2p2nqsd0c76g0' -ErrorAction SilentlyContinue |
        ForEach-Object {
            $candidate = Join-Path $_.FullName 'app\Codex.exe'
            if (Test-Path -LiteralPath $candidate) {
                Get-Item -LiteralPath $candidate
            }
        } |
        Sort-Object FullName -Descending

    if ($matches) {
        return $matches[0].FullName
    }

    $running = Get-CimInstance Win32_Process -Filter "name = 'Codex.exe'" -ErrorAction SilentlyContinue |
        Where-Object { $_.ExecutablePath -and $_.ExecutablePath -like "*\OpenAI.Codex_*\app\Codex.exe" } |
        Select-Object -First 1

    if ($running) {
        return $running.ExecutablePath
    }

    throw "Codex.exe not found. Start Codex once normally, then run this script again, or update Find-CodexExe with the installed path."
}

$codexExe = Find-CodexExe
$originalPath = [Environment]::GetEnvironmentVariable('PATH', 'Process')

$gitFiltered = Remove-PathEntries -PathValue $originalPath -ShouldRemove {
    param($entry)
    $normalized = $entry.TrimEnd('\')

    $normalized -ieq 'C:\Program Files\Git\cmd' -or
    $normalized -ieq 'C:\Program Files\Git\mingw64\bin' -or
    $normalized -ieq 'C:\Program Files\Git\usr\bin' -or
    $normalized -match '(?i)\\Git\\(cmd|mingw64\\bin|usr\\bin)$'
}

$newPath = $gitFiltered.Path
$removed = New-Object System.Collections.Generic.List[string]
$gitFiltered.Removed | ForEach-Object { $removed.Add($_) }

if ($RemovePowerShell) {
    $powerShellFiltered = Remove-PathEntries -PathValue $newPath -ShouldRemove {
        param($entry)
        $normalized = $entry.TrimEnd('\')

        $normalized -match '(?i)\\WindowsPowerShell\\v1\.0$' -or
        $normalized -match '(?i)\\PowerShell\\[0-9]+$'
    }

    $newPath = $powerShellFiltered.Path
    $powerShellFiltered.Removed | ForEach-Object { $removed.Add($_) }
}

Write-Host "Codex executable:"
Write-Host "  $codexExe"
Write-Host ''
Write-Host "Removed PATH entries for child process:"
if ($removed.Count -eq 0) {
    Write-Host "  none"
}
else {
    $removed | ForEach-Object { Write-Host "  $_" }
}

if ($DryRun) {
    Write-Host ''
    Write-Host "Dry run only. Codex was not started."
    exit 0
}

$env:PATH = $newPath

Start-Process -FilePath $codexExe -WorkingDirectory $env:USERPROFILE

I collected a different type of evidence that may help narrow the lifecycle issue.

This was reproduced twice in a valid Git repository (not an invalid or empty .git case).

Starting from a clean baseline of approximately 0–4 git.exe processes, a single long-running Codex task gradually accumulated a stable pool of approximately 255–273 concurrent git.exe processes.

The oldest Git process reached 105–127 minutes of lifetime while the pool size remained nearly constant.

When the task was stopped, the process pool collapsed almost immediately:

257 → 26 → 4 git.exe

This behaviour was reproduced twice from a clean baseline.

That suggests the issue may not only be Git polling frequency, but also Git subprocess lifetime or task-scoped cleanup.

After reaching approximately 257 concurrent git.exe processes, the pool size remained almost constant while the age of the oldest process continued increasing. This suggests a long-lived retained process pool rather than an unlimited process creation loop.

@azsama

still not fixed @azsama

this is NOT fixed, re-open it.
This crashed my PC, about 4 times, before I found out why.

I thought this would've been fixed like a year ago, however it's still wrecking my PC.
Back to anthropic we go.

Navigation Menu

Repository navigation

Windows: Codex spawns many Git for Windows processes causing sustained high CPU after recent update #22085

What happened?

Impact

Environment

Screenshot / observation

Expected behavior

Actual behavior

Request

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Windows: Codex spawns many Git for Windows processes causing sustained high CPU after recent update #22085

Description

What happened?

Impact

Environment

Screenshot / observation

Expected behavior

Actual behavior

Request

Activity

github-actions commented on May 11, 2026

Bobini1 commented on May 11, 2026

azsama commented on May 11, 2026

zhiyangyou commented on May 12, 2026

zhiyangyou commented on May 12, 2026

jimzhaoxiaojun commented on May 13, 2026

wurucu commented on May 14, 2026

cclyfblink commented on May 15, 2026

Baccan commented on May 17, 2026

EcMarius commented on May 28, 2026

kevinfoley commented on Jun 10, 2026

adamgwinn commented on Jun 12, 2026

SbiriJJ commented on Jul 6, 2026

bobbanj commented on Jul 24, 2026

Ronkiro commented on Oct 1, 2026

pwncc commented on Oct 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions