Worktree/temp-clone lifecycle broken: auto-delete and worktree-keep-count not enforced; managed-worktree list reports zero while 118 multi-GB run copies (202 GB) accumulate in /tmp

[alanxchen85]

Summary

Codex has no working lifecycle management for the per-run repository copies it
creates during multi-session agent orchestration. On my machine this produced
118 full-repo working-tree copies totaling 202 GB in /private/tmp over ~3 days,
none of which were registered anywhere Codex can see, and none of which were ever
cleaned up. Meanwhile Codex's own managed-worktree store reports zero worktrees,
and the configured worktree-keep-count = 10 cap had no observable effect.

This drove a 16 GB-RAM laptop with a ~926 GB volume to 94% full / 61 GB free.

Environment

• codex --version → codex-cli 0.145.0
• Codex desktop app (installed via codex app), Sparkle build 4505
• macOS 26.5.1 (build 25F80), arm64
• Repository under test: a single ~3 GB repo (large .git + build artifacts)

Configured settings

From ~/.codex/config.toml:

[desktop]
...
worktree-keep-count = 10

This was previously 15 and lowered to 10. The "automatically delete old
worktrees" toggle was enabled in the desktop UI, but that toggle is not persisted
to config.toml at all — worktree-keep-count is the only worktree-related key
written anywhere in the config. There is no way to verify from disk whether
auto-delete is actually on, which is part of the problem.

Expected behavior

1. Old run copies are automatically deleted once the auto-delete setting is on.
2. The total number of retained copies is capped at worktree-keep-count.
3. Some interface — CLI or UI — accurately lists what Codex currently has on disk,
   so the cap and the cleanup can be verified.

Actual behavior

1. Codex's managed-worktree store is empty while sessions still reference it.

~/.codex/worktrees/ contains zero entries:

$ ls ~/.codex/worktrees | wc -l
0
$ du -sh ~/.codex/worktrees
  0B	~/.codex/worktrees

…yet ~/.codex/.codex-global-state.json still contains live session records whose
cwd points into that store, e.g.:

{"projectKind":"local","projectId":"<uuid>","cwd":"~/.codex/worktrees/3f3d/project-a1b2","pendingCoreUpdate":false}
{"projectKind":"local","projectId":"<uuid>","cwd":"~/.codex/worktrees/62eb/project-a1b2","pendingCoreUpdate":false}

So the registry and the filesystem disagree, and the count Codex reports (zero) is
not the amount of disk actually consumed by its runs.

2. There is no CLI surface to list or prune worktrees at all.

codex --help on 0.145.0 exposes no worktree subcommand — the full command list is
exec, review, login, logout, mcp, plugin, mcp-server, app-server, remote-control, app, completion, update, doctor, sandbox, debug, apply, resume, archive, delete, unarchive, fork, cloud, exec-server, features, help. codex debug only offers
models, app-server, prompt-input. There is no way to ask Codex what it has on
disk or to make it clean up.

3. Per-run copies accumulate unregistered and uncapped.

Measured live on 2026-07-25 before I cleaned up manually:

$ find /private/tmp -maxdepth 1 -type d -name 'project-*' | wc -l
118
$ du -sh /private/tmp
202G	/private/tmp
$ du -sh /private/tmp/project-*/ | sort -rh | head -5
9.2G	/private/tmp/project-a1b2-overnight/
5.1G	/private/tmp/project-a1b2-release-cc7ba01d.i4HxqR/
5.1G	/private/tmp/project-a1b2-release-9ec12165.kgSFVl/
5.1G	/private/tmp/project-a1b2-be1.kY8muT/
4.9G	/private/tmp/project-a1b2-rc-validate.DKpwkJ/

Plus 345 loose per-run files at the same level (logs/artifacts), for ~460 stray
entries total. Individual copies ran 3–9 GB each; 16 carried a full .git.

4. git worktree list cannot see them either.

Of those 118 directories, exactly one appears in git worktree list for the
source repo. The rest are plain working-tree copies with no .git file, so they are
invisible to both Codex and git:

$ ls -a /private/tmp/project-a1b2-release-cc7ba01d.i4HxqR | head -4
.
..
.agents
.claude
$ file /private/tmp/project-a1b2-release-cc7ba01d.i4HxqR/.git
cannot open '.../.git' (No such file or directory)

The git worktree list output that is registered also shows stale entries marked
prunable that were never pruned.

Impact

• 202 GB of dead weight on a 926 GB volume already at 94% capacity (61 GB free),
  on a 16 GB-RAM development machine. A few more orchestration runs would have
  exhausted the disk mid-session.
• Because nothing is registered, the user has no way to discover this short of
  running du on /tmp by hand, and no way to have Codex reclaim it.
• The worktree-keep-count setting silently does nothing for this class of copy,
  which is misleading — the UI presents a cap that is not enforced against the
  storage actually being consumed.

Repro sketch

1. Open a repo with a large working tree (~3 GB including .git and build output).
2. Enable auto-delete of old worktrees in the desktop app and set
   worktree-keep-count = 10.
3. Run multi-session agent orchestration against that repo over several days —
   parallel review/validation/release lanes, each of which materializes its own
   copy of the tree under /tmp.
4. Observe: ls ~/.codex/worktrees stays empty and the app reports no worktrees,
   while du -sh /private/tmp climbs into the hundreds of GB and the copy count
   far exceeds worktree-keep-count.

The underlying gap

Per-run temp copies appear to be created outside the managed-worktree lifecycle:
they are not written under ~/.codex/worktrees/, not registered as git worktrees,
not recorded in any state Codex reads back, and have no teardown hook tied to
session or run completion. Consequently neither the auto-delete setting nor
worktree-keep-count can ever apply to them, and no interface reflects their
existence.

Two things would fix this:

1. Register every run-scoped copy in the same store the cap and auto-delete read
   from, and tear it down when its session/run ends (including on crash — a
   startup sweep of orphaned entries).
2. Expose a CLI surface (codex worktree list / codex worktree prune) so the
   state is inspectable and reclaimable without manual du/rm. Right now codex doctor does not report disk consumed by run copies either; it would be a
   reasonable place to surface it.

Paths above are sanitized; happy to provide any additional detail from the local
state files on request.

[LIghtJUNction]

This has seriously affected my user experience.

[romainsimon]

Adjacent real-world data point from Codex usage on macOS (measured 2026-08-25):

Codex-related storage	Size
Codex-created/named Git worktrees	45.3 GiB
Total storage attributable to Codex, including sessions, worktrees, caches and app data	~117.7 GiB

This is not exactly the same filesystem case as the original report: these are registered Git worktrees stored in a central development worktree directory, not unregistered clones under /tmp. The user-facing lifecycle problem is similar: worktrees accumulated across many Codex tasks with no global storage inventory or safe cleanup workflow.

Several clean worktrees were 3–4 GiB each. However, “clean” does not mean “safe to delete”: Codex must also preserve dirty worktrees, open or unmerged work, and branches still associated with active pull requests.

It would help if Codex:

• inventoried every worktree it creates, regardless of storage path;
• displayed size, dirty state, branch and related task/PR state;
• automatically removed only worktrees whose work is confirmed merged or abandoned;
• offered a dry-run/safe-prune command and a disk-space warning.

Project names and contents are intentionally omitted.

[tonydehnke]

I can reproduce the keep-count failure on macOS with a different variant: these are normal, Git-registered ChatGPT/Codex-managed worktrees, not unregistered /tmp copies.

• ChatGPT desktop 26.825.32147; Codex CLI 0.151.0
• worktree-keep-count = 10
• 61 registered worktrees remain under ~/.codex/worktrees
• Disk use is approximately 100 GB; each Rails checkout has about 1.3 GB of node_modules, plus build/temp output
• git worktree list sees all 61; no stale Git registrations remain after git worktree prune
• The current Codex sidebar shows only a small active project-chat list, including the active audit chat, rather than anything close to 61 worktree chats.

This persists on a newer version than the original report. It appears the configured retention limit is not being enforced for ordinary managed worktrees either, or the app is treating long-gone chats as protected without exposing that state. I have not manually removed these registered worktrees because that could discard recoverable work.