[Windows/WSL] Internal Git snapshot hashes large untracked files and can fill the WSL disk

What version of the Codex App are you using?

Not captured yet. The issue occurs in Codex Desktop on Windows with Codex configured to run inside WSL.

What platform is your computer?

• Windows + WSL2
• Codex Desktop
• Project opened from the WSL filesystem

What issue are you seeing?

Codex Desktop appears to automatically create Git-based workspace snapshots/checkpoints after user turns or while computing workspace diffs. In a repository containing a large unignored file (~11.4 GB), this caused Git object storage to grow until the WSL virtual disk was effectively full. In my case, Git-related disk usage grew to roughly 200 GB and WSL could no longer start normally because there was no free space left.

The Git command observed as a child of Codex was:

git -c core.hooksPath=/dev/null -c core.fsmonitor= \
  add --sparse --pathspec-from-file=- --pathspec-file-nul

This appears to be an internal Codex snapshot/diff operation rather than a command requested by the user. No manual git add, commit, or push was requested.

Because git add hashes untracked files into Git objects, a large untracked artifact can cause very large writes into .git/objects, even when Codex is only trying to capture an internal snapshot for diff/undo/recovery purposes.

The failure mode is particularly severe under WSL because the Git object growth expands/fills the WSL ext4.vhdx. Once the virtual disk is full, WSL itself may fail to start, which makes recovery significantly harder.

Steps to reproduce

1. On Windows, enable Codex Desktop with WSL integration.
2. Open a Git repository located inside WSL.
3. Put a large file in the repository working tree that is not ignored (in my case about 11.4 GB).
4. Use Codex normally for several turns; do not manually stage or commit anything.
5. Observe Codex-spawned Git processes such as:

git -c core.hooksPath=/dev/null -c core.fsmonitor= \
  add --sparse --pathspec-from-file=- --pathspec-file-nul

1. Monitor .git/objects and WSL disk usage.
2. Disk usage can grow dramatically as the large untracked file is hashed for Codex's internal snapshot/diff path.

Expected behavior

Codex's automatic snapshot/diff mechanism should be bounded and should not be able to exhaust the user's disk because of large untracked files.

Possible safeguards:

• Inspect untracked file sizes before hashing their contents.
• Skip or summarize files above a reasonable size threshold unless the user explicitly opts in.
• Enforce a per-snapshot maximum byte/file budget and timeout.
• Avoid writing snapshot-only blobs into the repository's real object database; use an isolated temporary object directory if hashing is required.
• Stop retrying after a snapshot exceeds limits or fails because of disk space.
• Surface a warning when large untracked files are skipped.
• Provide a documented option to disable automatic Git snapshots/checkpoints for a workspace.

Actual behavior

Codex silently invokes Git staging-style commands for its internal snapshot/diff workflow. With a large unignored file, this can create enough Git-object data to fill the WSL virtual disk and prevent WSL from starting normally.

Impact

This is more than a performance issue: disk exhaustion can make the development environment unusable and require recovery from the Windows side before WSL can start again.

Related issues

This appears related to, but is not identical to:

• #28750 — Codex.app repeatedly runs git add -A and fills .git/objects/pack
• #30477 — large unignored data causes Codex Git workers to consume heavy resources
• #19588 — ghost snapshots filling disk on a large trusted workspace

This report adds a Windows/WSL-specific failure mode, including the observed add --sparse --pathspec-from-file=- --pathspec-file-nul snapshot command and the consequence that filling the WSL virtual disk can prevent WSL from starting.