Windows Codex Desktop repeatedly leaks full-size Git LFS temp copies while refreshing a repo

[Jiuxiao-yunwai]

What version of the Codex App are you using?

OpenAI.Codex 26.715.10079.0 (Windows x64)

Platform

• Windows 10.0.26200.0 x64
• Git 2.55.0.windows.2
• Git LFS 3.7.1

Summary

While a local Git repository is open in Codex Desktop, repository-state/diff refreshes repeatedly invoke Git LFS processing for a large untracked file that matches an LFS attribute. Each refresh leaves another near-full-size file in .git/lfs/tmp, causing unbounded disk growth. In this incident, the directory grew past 42 GiB and resumed growing immediately after cleanup.

This is severe because merely keeping/using a Codex task open can fill the disk without the user requesting staging, committing, or any LFS operation.

Repository setup

.gitattributes contains:

*.db* filter=lfs diff=lfs merge=lfs -text

The working tree contains:

• one tracked LFS database, about 551.6 MiB
• one untracked backup database, also about 551.6 MiB, matching *.db*

The database content/path is not relevant; any sufficiently large untracked file matching an LFS rule should reproduce it.

Observed behavior

1. With the Codex task active, git-lfs processes repeatedly appeared around repository refreshes/turns.
2. .git/lfs/tmp accumulated files approximately the size of the database.
3. Initial measurement: 90 temporary files, 42.046 GiB reclaimed after stopping git-lfs and deleting .git/lfs/tmp contents.
4. The growth immediately resumed: 11 additional files consumed 5.13 GiB.
5. A later five-second observation showed the temp directory grow from one partial file (538.3 MiB) to two files (556.4 MiB total).
6. Adding only the untracked backup file to .git/info/exclude, stopping the active git-lfs process, and cleaning .git/lfs/tmp stopped the growth. A five-second recheck stayed at zero files.

git lfs prune --dry-run did not account for the problem: it reported only 288 MiB prunable because the tens of GiB were in .git/lfs/tmp, not normal LFS objects.

The tracked database's SHA-256 matched its indexed LFS OID, so it was not modified.

Steps to reproduce

1. On Windows, create/open a Git repository in Codex Desktop.

2. Add an LFS rule such as:

   *.db* filter=lfs diff=lfs merge=lfs -text

3. Place a large untracked file such as backup.db in the working tree.

4. Keep the local Codex task active and perform turns/tool calls that cause repository state/diff refreshes.

5. Monitor .git/lfs/tmp and git-lfs processes.

Expected behavior

• Background Git status/diff rendering must not run clean/LFS filters over large untracked files merely to display changes.
• Cancellation or refresh replacement must terminate child processes cleanly and remove partial LFS temp files.
• Repository polling should be debounced/bounded so it cannot consume disk without limit.
• At minimum, Codex should detect and skip or cap large untracked files during snapshot/diff construction.

Actual behavior

Full-size or partial copies accumulate in .git/lfs/tmp on repeated refreshes until the disk is exhausted.

Workaround

Adding the large untracked file to .git/info/exclude stops the loop:

/data/path/backup.db

This is only a workaround; opening a repository containing any large, unignored file matching an LFS rule remains dangerous.

Related issues

• Possible infinite disk write / storage corruption behavior in Windows Codex app #23681 — possible infinite disk writes involving Git LFS on Windows
• Windows Codex app repeatedly spawns git.exe/conhost.exe in Git workspaces, possibly contributing to Nonpaged Pool growth #26812 — Codex Desktop repeatedly spawns Git processes in Windows Git workspaces
• Codex.app repeatedly runs git add -A without user request, filling .git/objects/pack #28750 — Codex Desktop repeatedly runs Git staging operations and fills .git/objects/pack

This report narrows the failure to repeatable full-size files under .git/lfs/tmp caused by a large untracked file matching an LFS attribute.

[github-actions]

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

• macOS Desktop: main thread spawns git ~50/s — uncached core.fsmonitor probe + per-file untracked diffs in repos with large untracked dirs #34005
• [Windows][26.715.10079.0] Opening Codex spawns rapid Git/PowerShell churn and drives WMI + Defender CPU to ~60% #34854

Powered by Codex Action

[kan030603]

Confirmed on the current Windows desktop build with a tracked-file variant that is not covered by the original untracked-file reproduction.

Environment

• OpenAI Codex Desktop 26.727.6591.0 (Windows x64)
• Windows 11 10.0.26200 x64
• Git 2.52.0.windows.1
• Git LFS 3.7.1

Variant: tracked and protected LFS databases

The repository contained 24 tracked *.db LFS files. One is a live SQLite database (~123 MiB); the others are immutable snapshots/test databases. There was no user-requested staging or LFS operation.

While a local task was active, ChatGPT.exe directly spawned commands shaped like:

git.exe -c diff.mnemonicPrefix=false -c diff.noprefix=false \
  -c core.quotePath=false -c core.hooksPath=NUL -c core.fsmonitor= \
  diff --no-ext-diff --no-textconv --color=never \
  --src-prefix=a/ --dst-prefix=b/ <task-base-commit> \
  --find-renames --raw --no-abbrev --numstat -z

Those commands spawned git-lfs.exe filter-process. The diff was repeatedly replaced/cancelled, and numeric partial files appeared in .git/lfs/tmp every 1-2 seconds.

Measured impact

• .git/lfs/tmp: 206 files / 9,803,734,016 bytes
• About 90 seconds later: 255 files / 12,762,767,360 bytes
• Later in the same active task: 1,095 files / 63,231,792,128 bytes
• The user observed the directory at roughly 250 GB and the data drive completely full before the child processes exited and much of the temporary data disappeared.
• .git/lfs/objects also accumulated 489 completed objects / 30,103,741,138 bytes. Of those, 452 objects / 28,237,992,658 bytes were neither reachable from any Git ref nor equal to any current database content.

This was real on-disk growth, not just an Explorer size-reporting error.

skip-worktree alone is insufficient

Setting skip-worktree on all 24 tracked database paths reduced some work, but the app's task-base-to-working-tree diff still launched the LFS clean filter for tracked database files. Temp files continued to appear.

A robust local workaround was to keep the repository-level LFS rules for clone/restore, while adding a worktree-only override in .git/info/attributes:

*.db -filter -diff -merge
*.db-wal -filter -diff -merge
*.db-shm -filter -diff -merge

Combined with skip-worktree, this stopped the filter loop. Ten consecutive commands matching the Codex-generated diff shape completed with:

• .git/lfs/tmp: 0 bytes before and after
• .git/lfs/objects: byte-for-byte unchanged
• no git-lfs filter-process left running

The project now creates snapshot pointers explicitly in an isolated Git index so normal clone/restore can keep using Git LFS without exposing live database files to background diffs.

Suggested product-side safeguards

1. Do not run clean/LFS filters for background diff metadata collection.
2. Do not restart a repository refresh in response to writes under .git/lfs/tmp or .git/lfs/objects.
3. On cancellation, terminate the full Git/LFS process tree and remove partial temp files.
4. Debounce/serialize repository refreshes and cap temporary disk use.
5. Add a regression test for tracked, smudged LFS files when calculating a task-base-to-working-tree diff.

No private database, repository path, credentials, or application data are attached to this report.