Severe: Codex Desktop can hammer disks in game/media/ML repos with many binary assets, risking SSD wear #30612

Summary

This is likely a Codex Desktop / Codex GUI issue rather than a CLI-only issue, but I am filing it here because openai/codex appears to be the closest public feedback path.

Codex Desktop appears to run an automatic Git snapshot / diff collection path from the GUI process. In a repository with many large untracked generated binary artifacts, the GUI repeatedly spawned Git commands such as:

git ... add -- <generated-audio-dir>/...
git ... add -A
git ... diff --find-renames --numstat -z

Those commands forced Git to read/hash gigabytes of untracked binary content. On my machine this caused sustained disk reads in the hundreds of MB/s range. This is not just a small performance bug: if this path writes Git objects, temp indexes, or retries repeatedly, it can rapidly consume SSD write endurance. From a user perspective, the app can look like it is trying to burn through the SSD in the background.

Please treat this as a high-severity reliability and hardware-safety issue.

Affected scenario

The problematic scenario is very concrete: a normal Git repository that contains a large number of binary assets or generated artifacts.

Examples include:

• game projects with generated sprites, CGs, audio, voice lines, screenshots, and backup asset folders,
• media/design projects with many images, videos, exported previews, or source renders,
• ML/data projects with model files, datasets, generated samples, checkpoints, or evaluation outputs,
• web/app projects with large generated bundles, screenshots, fixtures, or binary test artifacts.

This can happen before a user has finished tuning .gitignore, or when generated assets are intentionally kept in the working tree but not committed. That is not an exotic edge case. It is a common development state for asset-heavy repositories.

In this scenario, Codex Desktop should not treat every untracked binary as something to hash, snapshot, or diff automatically. The safe default should be to summarize and skip large binaries unless the user explicitly opts in.

Why this is dangerous

Generated media-heavy projects are common: games, ML/data projects, design tools, video/audio workflows, browser assets, etc. These repos often contain large untracked binary files before the user has finalized .gitignore.

An assistant app should not automatically perform unbounded Git content reads or git add-style hashing over such files without:

• a clear user opt-in,
• strict file-count and byte budgets,
• binary/generated-artifact skipping,
• cancellation when the related thread is archived/interrupted,
• and UI visibility that this expensive background work is happening.

In the observed case, killing the Git child process did not stop the behavior; Codex GUI immediately spawned another Git process. Archiving the active Codex threads also did not cancel already queued Git snapshot work.

Observed impact

System-level disk throughput repeatedly reached roughly:

250-438 MB/s

Example iostat samples:

435.51 MB/s
428.75 MB/s
438.27 MB/s
344.32 MB/s
409.11 MB/s
394.35 MB/s

At the same time, per-process sampling showed the current codex app-server was not reading anywhere near that volume:

<codex-app-server-pid> read=16.50MB write=9.93MB over 10s

The high I/O was instead traced to short-lived git children of the Codex GUI process.

Evidence

Git children of Codex GUI were responsible

Repeated process polling showed Git commands whose parent was the Codex GUI process:

<system-git-binary>
  -c diff.mnemonicPrefix=false
  -c diff.noprefix=false
  -c core.quotePath=false
  -c core.hooksPath=/dev/null
  -c core.fsmonitor=
  diff --no-ext-diff --no-textconv --color=never
  --src-prefix=a/ --dst-prefix=b/
  <base-tree-or-commit> ...
  --find-renames --numstat -z

Other observed commands:

git -c core.hooksPath=/dev/null -c core.fsmonitor= add -- <generated-audio-dir>/...
git -c core.hooksPath=/dev/null -c core.fsmonitor= add -A

fs_usage showed Git page-ins on generated binary files

fs_usage -w -f filesys -t 5 showed heavy file page-ins from Git processes reading generated binary assets such as:

<generated-audio-dir>/generated_audio_0001.wav
<generated-audio-dir>/generated_audio_0002.wav

Aggregated examples from one 5 second capture:

396570624 bytes  10599 events  git.<pid-a> PgIn[A]
304250880 bytes   8978 events  git.<pid-b> PgIn[A]
253493248 bytes   7954 events  git.<pid-c> PgIn[A]
234450944 bytes   6984 events  git.<pid-d> PgIn[A]
112254976 bytes   3970 events  git.<pid-e> PgIn[A]
 82366464 bytes   2883 events  git.<pid-f> PgIn[A]
 74018816 bytes   2359 events  git.<pid-g> PgIn[A]

Those listed Git processes alone account for about 1.46 GB of page-ins in 5 seconds.

The repo had many untracked binary artifacts

Before mitigation:

<generated-audio-dir>: 17093 untracked wav files, about 5.8 GB
untracked images: 1156 files, about 1.6 GB
largest untracked image directory: about 706 MB

This is large, but not exotic for generated-media projects.

Killing Git did not stop the loop

After killing one Git child:

git children before kill: <git-pid-a>
git children after kill: <git-pid-b>

The new Git process was again a child of the Codex GUI process.

Mitigation that stopped the issue

Adding .gitignore rules to hide the large generated binary artifacts immediately stopped the runaway Git work:

<generated-audio-dir>/

<generated-image-dir>/**/*.png
<generated-image-dir>/**/*.jpg
<generated-image-dir>/**/*.jpeg
<generated-image-dir>/**/*.webp
<generated-image-dir>/**/*.gif

<backup-artifact-dir>/**/*.png
<backup-artifact-dir>/**/*.jpg
<backup-artifact-dir>/**/*.jpeg
<backup-artifact-dir>/**/*.webp
<backup-artifact-dir>/**/*.gif

After mitigation:

git ls-files --others --exclude-standard -- <generated-audio-dir>  => 0 visible files
untracked non-ignored image_count                                 => 0
git_processes_seen in a 6-8 second polling window                  => 0

iostat dropped from hundreds of MB/s to low or near-idle samples:

29.49 MB/s
0.28 MB/s
0.53 MB/s
0.55 MB/s
0.41 MB/s

This strongly suggests the Git auto-snapshot path was the trigger.

Expected behavior

Codex Desktop should never perform unbounded background Git content reads over a user's repository.

Expected safeguards:

• Do metadata-only status first.
• Do not hash/read untracked binary files unless the user explicitly opts in.
• Do not run background git add -A over a real worktree.
• If a Git index is required internally, always use an isolated temporary GIT_INDEX_FILE.
• Enforce strict budgets:
  • max untracked files considered,
  • max total bytes read,
  • max per-file size,
  • max wall-clock time.
• Skip common binary/generated artifact extensions by default:
  • audio/video/image/archive/model files, etc.
• Cancel pending snapshot jobs when a thread is archived or interrupted.
• Debounce snapshot work across multiple Codex threads in the same repo.
• If a Git child is killed, do not immediately respawn it in a tight loop.
• Surface a UI warning, e.g.:

This repo has 17k untracked binary files / 5.8 GB.
Codex will skip them unless you explicitly include large generated assets.

Suggested fix

The safest design would be:

1. Run git status --porcelain / git ls-files --others --exclude-standard first.
2. Classify files by size and likely binary/generated type before reading content.
3. Only diff small text files.
4. For large binaries, report counts/path summaries only.
5. Require explicit user confirmation before indexing/hashing large generated artifacts.
6. Use a temp index only if absolutely necessary, and log that isolation clearly.

Diagnostic commands used

iostat -d -w 1 -c 12
sudo fs_usage -w -f filesys -t 5
pgrep -P <codex-gui-pid> -fl git
ps -axo pid,ppid,etime,%cpu,%mem,rss,command
git -C <repo> ls-files --others --exclude-standard
git -C <repo> status --porcelain=v1 --untracked-files=all

Closing note

This is severe because the behavior is automatic and invisible. A user can open a media-heavy repo in Codex Desktop and unexpectedly get hundreds of MB/s of sustained disk I/O from background Git children. In the worst case, if object/index writes happen repeatedly, this can burn SSD endurance quickly. Codex should fail safe here: skip large untracked binaries by default and ask before doing expensive snapshot work.