›_ Codex Issues
Codex Issues / #22151

Codex Windows app launched repeated `git add -A` processes in background, causing hundreds of `git-lfs filter-process --skip` processes

Open 💬 9 comments Opened May 11, 2026 by Coder666
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What issue are you seeing?

Codex.exe appeared to continue running in the background even though I did not have the Codex app window open. It repeatedly launched many git.exe add -A processes against my repository. Each git add -A spawned git-lfs.exe filter-process --skip, eventually creating a large number of Git/Git-LFS processes.

This appears to be a Codex Git/background task handling bug. Git LFS itself was not the initiating process; it was a child of the repeated git add -A commands.

Observed process chain:

Codex.exe PID 8516
-> git.exe add -A
-> git-lfs.exe filter-process --skip

Example process list excerpt:

42640 61660 git.exe git.exe add -A
48180 80692 git.exe git.exe add -A
86296 66500 git.exe git.exe add -A
33640 96260 git-lfs.exe "C:\Program Files\Git\mingw64\bin\git-lfs.exe" filter-process --skip
4052 50740 git-lfs.exe "C:\Program Files\Git\mingw64\bin\git-lfs.exe" filter-process --skip
...
45208 29912 git.exe "C:\Program Files\Git\cmd\git.exe" add -A

Parent process identification:

ProcessId : 29912
ParentProcessId : 8516
Name : Codex.exe
CommandLine : "C:\Program Files\WindowsApps\OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0\app\Codex.exe"

What steps can reproduce the bug?

Environment:
  • OS: Windows
  • App: Codex Windows app
  • Package path observed:

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

  • Repo uses Git LFS for large .stl / .jpg assets
  • Git LFS config included:

```gitconfig
[filter "lfs"]
clean = git-lfs clean -- %f
smudge = git-lfs smudge --skip -- %f
process = git-lfs filter-process --skip
required = true

Trigger/context:

I had unzipped a large archive into the repository. The repository contains many Git LFS-tracked assets. I did not intentionally run git add -A, and I did not have the Codex app visibly open at the time.

What is the expected behavior?

Expected behavior:
Codex should not repeatedly run git add -A in the background without explicit user action, especially in a repository with many large Git LFS-tracked assets. If Codex needs to inspect Git state, it should avoid staging files, or should do so only with explicit approval and concurrency limits.

Additional information

Actual behavior:
Codex repeatedly spawned git.exe add -A processes. This caused many git-lfs.exe filter-process --skip processes to run concurrently and made the machine/repo unstable until the Codex parent process was killed.

Resolution/workaround:
Killing the Codex parent process stopped the spawning

View original on GitHub ↗

9 Comments

github-actions[bot] contributor · 3 months ago

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

  • #20933
  • #22085

Powered by Codex Action

wnunezc · 3 months ago

i have the same issues, i am running this command to clean proccess in Windows:

taskkill /F /IM git.exe /T & taskkill /F /IM git-bash.exe /T & taskkill /F /IM bash.exe /T & taskkill /F /IM sh.exe /T & taskkill /F /IM ssh.exe /T & taskkill /F /IM ssh-agent.exe /T & taskkill /F /IM gpg-agent.exe /T

Be careful, this can negatively affect your environment if you depend on Git running or monitoring something.

wnunezc · 3 months ago

I'm about to cancel my subscription because of this bug

SYLQW · 3 months ago

在你的工作区的根目录中修改.gitignore文件为：
~~~

临时忽略整个仓库，减少 git add -A 的扫描开销

*
!.gitignore
~~~
可能对此情况有帮助，不过这也只是权宜之计

michaelraim · 3 months ago

Same issue. Causing CPU to reach 100%, cannot use the Windows client because of that.

Keesan12 · 3 months ago

The scary part here is not just repeated git add -A, it is that a write-capable background action seems to have escaped any clear user-facing admission gate. I would want Codex to separate Git inspection from Git mutation much more aggressively in background flows, with explicit receipts for who admitted a staging action and why. Otherwise repos with LFS or large assets turn a hidden helper action into a machine-stability problem very quickly.

wnunezc · 3 months ago

I find it sad that they haven't even assigned a technician or maintainer to this bug... don't the people at OpenAI realize that user experience is the main factor in losing customers?

xszaryx · 2 months ago

I hit a very similar issue on Windows with Codex Desktop, but in a large Unreal Engine 5.8 repo.

Context:

  • Codex Desktop version: OpenAI.Codex_26.623.5546.0
  • Local logs also showed Codex CLI/app version: 0.142.3
  • Project type: Unreal Engine 5.8 project
  • Integration: UE 5.8 MCP / Toolsets
  • Repo: very large Git LFS repo
  • Total project folder: about 319.8 GB
  • .git\lfs: about 166.8 GB
  • .uasset files: about 148.2 GB
  • Largest LFS/Unreal asset files: around 7.5-8.2 GB

What happened:

  • I had around 700GB free.
  • During a Codex-supervised Unreal animation export/sample workflow, multiple git-lfs processes appeared.
  • Task Manager showed several git-lfs processes writing around 140-220 MB/s.
  • Disk space dropped rapidly by hundreds of GB.
  • Closing Unreal Editor did not stop the disk usage growth.
  • Closing Codex stopped the Git/LFS activity and CPU usage dropped.
  • Reboot restored the missing disk space.
  • TreeSize showed the missing space under NTFS metadata/deleted data: $Extend\$Deleted around 770.8 GB.

I do not have the exact process tree anymore, but this looked strongly Codex-associated because closing Codex stopped the Git/LFS activity. This may be the same underlying issue: Codex-owned or Codex-supervised Git processes causing runaway Git LFS child-process/disk activity in large LFS repos.

<img width="879" height="526" alt="Image" src="https://github.com/user-attachments/assets/a519da6e-681f-4803-8ccf-bbb70bf8bf26" />
<img width="1125" height="518" alt="Image" src="https://github.com/user-attachments/assets/6c144414-9dda-4250-a44c-dc60dffc5e68" />

suiyuebaobao · 1 month ago

The repeated git add -A and downstream Git LFS process burst here is another Git-backed entry point that this workaround intentionally blocks.

I published a single-file Windows launcher for the original Microsoft Store/MSIX Codex app:

It starts Codex with a process-scoped GIT_DIR=NUL. On my machine, the stable trace changed from 247 new git.exe and 137 new taskkill.exe processes per 10 seconds to 0 and 0 over 15 seconds; WMI Provider Host fell from about 6.6% to 0.9%.

Usage: fully exit Codex from the Windows system tray, then run the script.

This is an unofficial workaround, not an upstream fix. It deliberately disables or limits Review, Changes, branch detection, commit, and other Git-backed Codex features. It does not patch Codex, modify repositories or Git configuration, write system environment variables, require elevation, terminate processes, or remove chat history. Launching Codex normally restores Git integration.