›_ Codex Issues
Codex Issues / #19588

Codex App ghost snapshot runs git add -A on trusted home directory and fills disk with tmp_pack files

Open 💬 7 comments Opened Apr 25, 2026 by bi-boo
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Codex App appears to run an internal repository / ghost snapshot mechanism that invokes git add -A for a trusted workspace. When the trusted workspace is the macOS home directory (/Users/ravenliu), Codex attempted to index the entire home directory and repeatedly created huge Git temporary pack files under ~/.git/objects/pack/tmp_pack_*.

This filled more than 200GB of disk space and made Codex itself unable to respond. I had to switch to Claude to diagnose and recover.

Environment

  • Product: Codex App
  • App version observed in process args: 26.422.30944
  • Platform: macOS
  • Workspace / cwd: /Users/ravenliu
  • Codex config previously contained a trusted home workspace:
[projects."/Users/ravenliu"]
trust_level = "trusted"

This home workspace is intentional for my workflow: I use Codex for cross-directory local automation and file operations across Documents, Projects, agent settings, Feishu/Lark tools, and other local directories. So the issue is not simply that the home directory was trusted; the issue is that the snapshot mechanism did not guard against this workspace shape.

What happened

Codex App spawned a Git process like this:

/Library/Developer/CommandLineTools/usr/bin/git add -A

The parent process was Codex App:

/Applications/Codex.app/Contents/MacOS/Codex

Git then wrote large temporary pack files such as:

/Users/ravenliu/.git/objects/pack/tmp_pack_*

At one point there were many multi-GB tmp_pack_* files. Cleanup recovered more than 200GB. After partial cleanup, ~/.git was still tens of GB, and new tmp_pack_* files kept appearing while Codex was running.

A later direct check from Codex also caught a live process:

/Library/Developer/CommandLineTools/usr/bin/git add -A

with Codex App as its parent.

Important detail: ghost_snapshot = false was not a sufficient recovery path

During recovery, we tried adding this to ~/.codex/config.toml:

ghost_snapshot = false

However, this did not immediately stop the running Codex App from continuing to create new tmp_pack_* files. My interpretation is that the running app/server had already loaded config or already had snapshot jobs in flight. In practice, Codex was unresponsive at that stage, so I could not rely on Codex itself to fix the problem.

The effective recovery steps were:

  1. Use another assistant/tooling path because Codex was not responding.
  2. Kill the Codex-spawned git add -A process.
  3. Remove the accidental home-level ~/.git repository.
  4. Remove the trusted home project entry from ~/.codex/config.toml.
  5. Verify no git add -A process or tmp_pack_* files remained.

Why this is severe

Using Git internally for snapshot / undo / diff is understandable for normal code repositories. But applying git add -A to a trusted home directory is unsafe.

A home directory can include:

  • Documents/
  • Downloads/
  • Library/
  • app data
  • caches
  • videos and large binaries
  • private files
  • cloud sync folders

The result was unbounded disk growth, failed Git pack creation, and repeated tmp_pack_* leftovers.

Expected behavior

Codex should add guardrails around repository / ghost snapshot:

  • Detect home directories such as /Users/<name> and skip snapshots by default.
  • Detect very large workspaces and disable snapshots automatically.
  • Avoid running git add -A over user home, root directories, external volume roots, or other broad filesystem roots.
  • Exclude obvious non-project directories by default, such as Library/, Downloads/, .Trash/, caches, app data, and large media files.
  • Stop retrying after snapshot failure.
  • Clean up failed tmp_pack_* files.
  • Surface a clear warning in the UI: snapshot / undo disabled because this workspace is too large or looks like a home directory.
  • Provide a documented, reliable per-workspace config option to disable ghost snapshot / undo that takes effect predictably, or requires/recommends restart explicitly.

Actual behavior

Codex continued attempting snapshot/index operations against the home directory and repeatedly wrote large .git/objects/pack/tmp_pack_* files until manually stopped.

Workaround

The current workaround is to avoid having /Users/ravenliu as a Git repository and to remove the trusted home project entry. But this is not ideal because there are legitimate workflows where Codex needs broad read/write access across a user's home directory.

The product should support broad local workspaces while disabling Git snapshot behavior for them.

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 4 months ago

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

  • #18641

Powered by Codex Action

moeyster · 2 months ago

I hit the same Codex Desktop Mac issue as openai/codex#19588.

Codex appears to have treated my home folder (/Users/tonymoey) as a project/workspace. A home-level .git folder was created/used, and .git grew to around 76GB with large .git/objects/pack/tmp_pack_* files. Git status showed my whole home directory as untracked, including Downloads, Library, Desktop, Documents, and dotfiles.

I confirmed:

  • Platform: macOS
  • Product: Codex Desktop app
  • Bad Git root: /Users/tonymoey
  • .git size: ~76GB
  • Git commits: 0
  • Git remotes: none
  • Codex config previously had /Users/tonymoey as a trusted project
  • Removing ~/.git and removing the trusted home project fixed the immediate disk issue

Expected behavior:
Codex Desktop should warn or block users from opening/trusting a whole home directory, or disable snapshot/Git behavior automatically for home folders and very large workspace roots. It should not run Git snapshot/index behavior over /Users/<name> without strong guardrails.

meanderix · 2 months ago

This appears also to be an issue when using the Codex app with WSL (i.e. from within the Windows Desktop app). A 13GB .git folder was added to my WSL home folder.

  • Platform: Windows
  • Product: Codex Desktop app
  • Date: 2026-06-10
  • Bad Git Root: /home/[username]
  • .git size: ~13GB
  • Git commits: 0
  • Git remotes: none
  • Two files in .git/objects/pack occupy 13GB in total (tmp_pack_C3AJjd, tmp_pack_Qi22Qv)

My experience with the Codex Desktop app was that it was quite slow and that there was a substantial initial delay when posting a message in the chat (the project root was not located within WSL and it certainly did not contain 13GB of data).

BTW: This also happened during a workshop session arranged by OpenAI to demonstrate the Codex app! We were using a temporary workspace where we logged in with a key provided specifically for this workshop.

Related: #28750

Magaav · 2 days ago

Confirmed the same underlying failure in a normal Git repository (not a home-directory Git root), using the Codex VS Code extension.

Environment

  • Product: Codex VS Code extension
  • Extension: openai.chatgpt 26.818.61809
  • OS: Ubuntu Linux, arm64
  • Git: 2.43.0
  • Repository root: /local
  • Filesystem: 96 GB root volume

Exact internal operation

The extension logs identify the writer as turn_diff_analytics / turn-diff-capture-start:

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

The command is repeatedly canceled by Codex. Across the retained VS Code/Codex logs I found:

turn_diff_add_events=119
aborted=118
canceled=118
summed_duration_ms=1884942

On 2026-08-25, one abandoned pack had mtime 11:49:09.669336136. The Codex log records the corresponding command cancellation at 11:49:09.674, only ~5 ms later:

aborted=true
failureReason=canceled
requestKind=turn-diff-capture-start
source=turn_diff_analytics
subcommand=add
durationMs=3648

That timestamp correlation directly identifies canceled turn-diff staging as the tmp_pack_* producer. Routine VS Code git status calls completed in milliseconds and were not the writer. There were no Git maintenance timers, hooks, maintenance registration, custom GC settings, OOM events, or active manual repacks.

Repeated disk impact

This has recurred multiple times in the same repository:

  • 2026-07-29: 93 abandoned Git temp files, 27.81 GiB
  • 2026-07-31: 88 abandoned temp files, 31.86 GiB
  • 2026-08-17: 126 tmp_pack_* files, roughly 29 GiB
  • 2026-08-25: 83 tmp_pack_* files, 20.16 GiB

The latest incident took / to 98% usage. Removing only Git-classified garbage restored about 20 GiB. A new small tmp_pack_* appeared immediately afterward on the next canceled turn-diff capture, demonstrating ongoing recurrence.

Requested fix

This needs cancellation-safe cleanup in the snapshot implementation, not only a workspace-root guard:

  1. On canceled/failed turn-diff capture, remove only the temporary packs created by that capture.
  2. Use an isolated temporary object directory/index so a canceled analytics operation cannot pollute the real repository object store.
  3. Bound snapshot input by file count and total bytes; exclude generated release/build artifacts.
  4. Stop retrying after repeated cancellation/failure or low-disk detection.
  5. Expose a documented per-workspace disable setting for turn-diff/ghost snapshot capture.

This reproduces in a legitimate repository root, so avoiding home-directory workspaces alone does not resolve the defect.

TannayeJiang · 2 days ago

I independently reproduced the same underlying failure on macOS, with additional forensic evidence that isolates the failure path and explains why the disk growth repeated byte-for-byte.

Environment

  • Product: Codex Desktop / ChatGPT desktop Codex surface
  • App build: 26.818.61809
  • Platform: macOS, arm64
  • Git: 2.52.x
  • Incorrect repository root: <HOME>/Documents
  • Repository state: unborn HEAD, no commits, no remote, no normal index

Disk impact

The accidental <HOME>/Documents/.git reached exactly 47.427 GiB.

Breakdown:

  • 7 abandoned objects/pack/tmp_pack_* files: 43.555 GiB total
  • 854 loose objects: about 3.42 GiB
  • 12 abandoned tmp_obj_* files: about 454 MiB

Each of the seven pack files was exactly:

6,680,966,759 bytes

All seven had the same complete SHA-256 digest. Therefore six copies alone were 37.333 GiB of byte-identical duplication. I am not posting the digest because the packs contain private local file content, but can provide it through a private maintainer channel.

Exact Codex operation

Codex logs identify the writer as:

source=turn_diff_analytics
requestKind=turn-diff-capture-start
cwd=<HOME>/Documents

The staging command was:

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

Codex used a temporary index through GIT_INDEX_FILE under the macOS temporary directory. That protected the user's real Git index, but new blobs and packs were still written into the real repository object database:

<HOME>/Documents/.git/objects

This appears to be the key isolation gap: the index is temporary, but the object directory is not.

Deterministic failure trigger

The broad Documents repository contained several unignored binary files larger than Git's default big-file threshold. Git's bulk check-in path streamed them into tmp_pack_*.

Later in the same staging operation, Git encountered a nested repository with an unborn HEAD:

<HOME>/Documents/<redacted-project>/.git

The outer git add then failed with:

error: '<redacted-project>/' does not have a commit checked out
fatal: adding files failed

By the time this late validation error occurred, approximately 6.68 GB had already been written into the temporary pack.

Codex removed its temporary index, but the tmp_pack_* file remained in the real object database.

Why seven identical copies appeared

The seven packs corresponded to seven separate user turns, not one Git command retrying internally. Each turn started a new turn-diff capture against the same repository state.

After failure there was no observed:

  • repository-level failure marker;
  • circuit breaker;
  • retry backoff;
  • stale tmp_pack_* cleanup;
  • reuse of the previous failed result.

Because each abandoned pack lacked a usable .idx/ref/finalized pack transaction, the next turn could not see or reuse it and rebuilt the same stream from the same files, in the same order, with the same Git version and the same late failure point. This explains the byte-identical output.

Additional findings

  • The large files copied into Git objects were unrelated to the active task; they were only in scope because the entire Documents directory had become the Git root.
  • There were no repository hooks, remotes, scheduled Git maintenance jobs, or manual repack processes responsible for the growth.
  • No evidence was found that the multi-gigabyte packs were uploaded; the confirmed impact was local object-store duplication and disk exhaustion risk.
  • The outer Documents/.git appears to have been created during an earlier Codex Desktop session, but the surviving evidence cannot distinguish a silent app-side initialization from a user clicking an initialization action, so I am not treating that attribution as proven.

Requested fixes

This case supports the existing requests in this issue and suggests several concrete implementation changes:

  1. Isolate both the index and object database for turn-diff capture, for example with a private temporary object directory and the real object store as a read-only alternate.
  2. Perform a read-only preflight before staging: repository health, unborn nested repositories, file count, total untracked bytes, maximum file size, free disk space, and risky roots such as Home/Documents/Desktop/Downloads.
  3. On failure or cancellation, remove only the index, refs, loose objects, and packs created by that capture transaction.
  4. Add a repository-level circuit breaker after the first deterministic snapshot failure; do not retry on every turn until the repository state changes or the user explicitly retries.
  5. Apply hard per-capture read/write budgets and a low-disk cutoff.
  6. Show the actual discovered Git root and estimated snapshot size in the UI before a broad workspace is processed.
  7. Default to capturing tracked files plus files modified by Codex, rather than blindly objectizing every untracked file in a broad workspace.

This is an independent reproduction of #19588, but it also demonstrates a deterministic late-failure path and proves cross-turn byte-identical amplification. Sanitized log excerpts, timestamps, size ledgers, and hashes can be provided privately if maintainers need them; raw packs and logs contain private user data and should not be posted publicly.

TannayeJiang · 2 days ago

Duplicate submission caused by a client retry. Please refer to the canonical forensic reproduction report here: https://github.com/openai/codex/issues/19588#issuecomment-5421638110

TannayeJiang · 2 days ago

Duplicate submission caused by a client retry. Please refer to the canonical forensic reproduction report here: https://github.com/openai/codex/issues/19588#issuecomment-5421638110