Codex Desktop app spawns Git on launch in read-only mode and leaves massive tmp_pack_/tmp_obj_ garbage in .git/objects on macOS

Resolved 💬 5 comments Opened Apr 5, 2026 by ukeich Closed Apr 30, 2026
💡 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 (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 --all
  • git gc --prune=now
  • git 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.toml override 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
  • .git grows 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 --full succeeds
  • git count-objects -vH returns small normal values
  • .git/objects shrinks 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_

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 4 months ago

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

  • #16786
  • #16269

Powered by Codex Action

1024ho · 4 months ago

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/.git directory, 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/.git myself. However, that hidden directory existed, and that is where the large unexpected growth occurred.

What I found locally:

  • $HOME/.codex was only about 154 MB
  • $HOME/.browseros was negligible
  • $HOME/Library/Application Support/Codex was only about 7.1 MB
  • but $HOME/.git had grown to about 74.7 GB
  • almost all of that was in $HOME/.git/objects

git count-objects -vH showed:

  • size: 23.20 GiB
  • size-pack: 3.62 GiB
  • size-garbage: 47.88 GiB

I also found these temporary garbage files:

  • 30 tmp_pack_* files
  • 4 tmp_obj_* files
  • total temp garbage size: 47.88 GB

The largest files were multiple tmp_pack_* files around 2.1–2.4 GB each.

Other details that may help:

  • $HOME/.git appears to have been created on 2026-03-27 20:18:34
  • the large temp pack/object files were created mostly on 2026-04-17 to 2026-04-18
  • this started around the time I installed/used the newer Codex computer-use/plugin features

So 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.

pharazone · 4 months ago

I have the same problem too, codex kept writing large pack files to my .git folder.

MitchK · 4 months ago

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.

ukeich · 3 months ago

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))