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

Open 💬 8 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 ↗

8 Comments

github-actions[bot] contributor · 2 months ago

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

#20933
#22085

Powered by Codex Action

wnunezc · 2 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 · 2 months ago

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

SYLQW · 2 months ago

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

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

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

michaelraim · 2 months ago

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

Keesan12 · 2 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 · 2 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 · 22 days 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.