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

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.

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

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

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