Codex scans filesystem for Git repositories without permission, triggers runaway under certain conditions

TL;DR

Codex triggers runaway disk growth when $HOME is a Git repo (writes massive tmp_pack_* under ~/.git/objects/pack)

Summary

When Codex runs in an environment where the user’s home directory is the Git repo root (/Users/<user>/.git, that happened by accident at some point), Codex-spawned Git operations (git add -- ...) traverse very large home paths, including private/app cache directories such as .npm and .local. This causes repeated packfile creation in ~/.git/objects/pack/tmp_pack_*, rapidly consuming disk.

Version

26.415.32059 (1789)

Environment

• macOS (APFS)
• Codex desktop app
• Observed on April 19–20, 2026 (Europe/Berlin timezone)

Reproduction Steps

1. Initialize a Git repository in the home directory:

``bash
cd ~
git init
``

1. Install and run Codex app

1. Use Codex

1. Watch disk space grow

Observed Behavior

• /System/Volumes/Data filled to ~99%
• ~/.git/objects grew in real time by ~833 MB in ~31 seconds (20:17:34 → 20:18:05 on 2026-04-19)
• ~/.git/objects/pack contained many tmp_pack_* files around ~1.8 GB each
• lsof showed git writing those files
• ps showed git processes were children of Codex.app and running commands like git add -- ... over home-scoped paths

Expected Behavior

Codex should not run broad Git/staging operations over a repo rooted at $HOME, or should at minimum guard/confirm before indexing sensitive and high-churn home directories.

Codex should not scan, touch or run commands outside the sandbox without explicit permission.

Root Cause (likely)

Codex Git integration executes in detected repo context. If repo root is $HOME, Git scope unintentionally includes private and high-volume directories, causing heavy object packing and runaway disk use.

Impact

• Severe disk pressure / near-out-of-space condition
• Unexpected scanning/indexing of private home paths due to repo boundary misconfiguration
• Potential repeated user disruption

Workaround Confirmed

Removing ~/.git immediately stopped the runaway growth and restored large free space (data volume dropped from near-full to ~36% used).