Codex Desktop app spawns Git on launch in read-only mode and leaves massive tmp_pack_/tmp_obj_ garbage in .git/objects on macOS
What version of the Codex App are you using (From “About Codex” dialog)?
Codex Version 26.325.31654 (1272)
What subscription do you have?
ChatGPT Pro
What platform is your computer?
Darwin 25.4.0 arm64 arm
What issue are you seeing?
Summary
On macOS Tahoe, Codex Desktop launches a Git process shortly after app startup even when my configuration is set to:
- Approval policy: Never
- Sandbox settings: Read only
I do not submit any prompt or intentionally trigger any action.
The app then causes my repository's .git directory to balloon rapidly due to garbage files such as:
.git/objects/pack/tmp_pack_*.git/objects/**/tmp_obj_*
In one incident this grew to roughly 250 GB of garbage.
In a later incident it grew again to about 17 GB before aborting the offending git process.
After switching to read-only / never-approve, the behavior still happened.
The spawned git process runs at 100% CPU until I quit Codex or switch to a project where this issue does not occur in which case the process immediately drops from the top activity users and the junk growth stops.
Expected behavior
If Codex is in read-only mode with approval policy set to Never, opening the app should not modify my repository, should not start mutating Git object storage, and should not leave temporary pack/object garbage behind.
Actual behavior
Opening Codex is enough to trigger Git activity against the repo.
The repo accumulates large amounts of tmp_pack_* / tmp_obj_* junk under .git/objects.git count-objects -vH reports huge garbage or loose-object growth.
Manual cleanup is required:
- remove
tmp_pack_* - remove
tmp_obj_* git reflog expire --expire=now --expire-unreachable=now --allgit gc --prune=nowgit fsck --full
The repo is healthy again after cleanup, but the problem reoccurs when Codex is launched again.
Environment
- Codex Desktop app on macOS Tahoe
- Repository is local
- No repo-level
.codex/config.tomloverride exists - User config is set to read-only / never approval
Evidence
Observed files:
.git/objects/pack/tmp_pack_*.git/objects/**/tmp_obj_*
Observed symptoms:
- background Git process starts on launch
.gitgrows dramatically without intentional user action- growth is in junk/temp object files, not meaningful repo history
Representative command output after cleanup showed the repo returning to a healthy state, e.g.:
git fsck --fullsucceedsgit count-objects -vHreturns small normal values.git/objectsshrinks back to a few hundred KB
Similar issue
This looks related to issue #7491, which mentions repositories accumulating very large .git garbage from orphaned tmp_pack_* files.
Request
Please investigate why the Desktop app is able to trigger Git object/temp-pack growth on launch in read-only mode, and whether a stale worktree/session/app-server state is bypassing the intended sandbox restrictions.
What steps can reproduce the bug?
Uploaded thread: 019d3171-8d83-7d22-866c-06685a381b14
What is the expected behavior?
_No response_
Additional information
_No response_
5 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Hi — I think I may be hitting the same macOS issue.
The confusing part in my case is that the storage growth happened under a hidden
$HOME/.gitdirectory, so at first it looked like my Mac had suddenly lost more than 100 GB of storage.I do not intentionally use my home directory as a Git repository, and I do not recall creating
$HOME/.gitmyself. However, that hidden directory existed, and that is where the large unexpected growth occurred.What I found locally:
$HOME/.codexwas only about 154 MB$HOME/.browseroswas negligible$HOME/Library/Application Support/Codexwas only about 7.1 MB$HOME/.githad grown to about 74.7 GB$HOME/.git/objectsgit count-objects -vHshowed:size: 23.20 GiBsize-pack: 3.62 GiBsize-garbage: 47.88 GiBI also found these temporary garbage files:
tmp_pack_*filestmp_obj_*filesThe largest files were multiple
tmp_pack_*files around 2.1–2.4 GB each.Other details that may help:
$HOME/.gitappears to have been created on 2026-03-27 20:18:34So in my case, this did not look like normal Codex state growth under
~/.codex. It looked more like Git temp/object garbage was being created under$HOME/.git, which made the storage blow-up much worse.I have the same problem too, codex kept writing large pack files to my .git folder.
Same issue for me. Why does Codex even scan my computer for code? I expect Codex to be fully sandboxed to particular projects, unless I give it permission.
Edit: I think I accidentally created the git repo myself at some point. But I am not sure. It could also be that codex created it.
It's been a while since I looked at this but checking the same problematic project just now did NOT spawn any wild Git processes as it consistently did in the past, so at least in my case this seems to have been fixed (Codex Version 26.422.71525 (2210))