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

Open 💬 3 comments Opened Jul 23, 2026 by Jiuxiao-yunwai

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

With the Codex task active, git-lfs processes repeatedly appeared around repository refreshes/turns.
.git/lfs/tmp accumulated files approximately the size of the database.
Initial measurement: 90 temporary files, 42.046 GiB reclaimed after stopping git-lfs and deleting .git/lfs/tmp contents.
The growth immediately resumed: 11 additional files consumed 5.13 GiB.
A later five-second observation showed the temp directory grow from one partial file (538.3 MiB) to two files (556.4 MiB total).
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

On Windows, create/open a Git repository in Codex Desktop.
Add an LFS rule such as:

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

Place a large untracked file such as backup.db in the working tree.
Keep the local Codex task active and perform turns/tool calls that cause repository state/diff refreshes.
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

#23681 — possible infinite disk writes involving Git LFS on Windows
#26812 — Codex Desktop repeatedly spawns Git processes in Windows Git workspaces
#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.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

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

#34005
#34854

Powered by Codex Action

kan030603 · 22 days ago

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.