Marketplace upgrade staging leak: 559 GB / 4,972 orphaned dirs in 41 days; cleanup janitor exists for curated clones but not marketplaces

Summary

Marketplace auto-upgrade leaked 4,972 staging directories totaling 559 GB in ~/.codex/.tmp/marketplaces/.staging/ over 41 days on my machine. That is the largest instance reported so far (previous high: 277 GB in #29994), so I'm adding it as a data point together with a consolidated root-cause read, because the seven existing reports are all still open with no fix PR.

Environment

• codex-cli 0.147.0 (musl standalone), Fedora 43
• ChatGPT Desktop for Linux with automation extensions active (app-server plugin sync)
• Two configured marketplaces (claude-plugins-official, cctools-codex-plugins), ~115 MB per full clone

What happened

• First leaked dir 2026-07-09, newest 2026-08-19; 4,972 dirs, 559 GB, ~10 GB/day while the desktop app was open.
• Completed leaked dirs are ~112–117 MB (full clones). The newest one was 18 MB, a partial clone — the process was killed mid-git clone. This matches the 30-second MARKETPLACE_UPGRADE_GIT_TIMEOUT trigger described in #38770: a ~115 MB marketplace on a residential connection can't finish in 30 s, so the upgrade dies every attempt, the revision metadata never updates, and the next sync retries — one orphaned clone per attempt, forever.

Root cause (from reading current main)

1. codex-rs/core-plugins/src/marketplace_upgrade.rs stages each upgrade into tempfile::Builder::new().prefix("marketplace-upgrade-").tempdir_in(install_root.join(".staging")).
2. TempDir cleanup only runs in its destructor. When the upgrade process is killed (clone timeout, OOM, SIGKILL, app-server teardown), the destructor never runs and the directory stays.
3. Nothing ever sweeps .staging: the only code in the repo touching that path is the code that creates entries (marketplace_upgrade.rs, marketplace_add/install.rs). There is no startup janitor for it.

The kicker is that the janitor pattern already exists in this codebase for the sibling leak: curated plugin startup sync has remove_stale_curated_repo_temp_dirs(...) (see #16004). It was never applied to marketplace staging.

Prior reports, all open

#21005 (2026-05-04, 187 GB) · #29994 (277 GB) · #30620 · #30794 · #32058 (also covers marketplace-backup-*) · #38770 (timeout trigger) · #39332 (filed 2026-08-19). Amplifiers: #36093 (concurrent processes), #34128 (annotated-tag upgrade loop), #24815 (the 30 s timeout itself).

Suggested fix

• On startup (or before each upgrade attempt), remove .staging/marketplace-upgrade-* entries older than some small age, mirroring remove_stale_curated_repo_temp_dirs.
• Optionally make the clone timeout proportional to marketplace size or resumable; shallow clones (#29994 suggestion) shrink the per-leak cost but don't stop the leak.

Happy to open a PR porting the existing janitor pattern to installed_marketplaces.rs if maintainers confirm that's the preferred shape.

Read codex-rs/core-plugins/src/marketplace_upgrade.rs and compare its staging behavior with remove_stale_curated_repo_temp_dirs and the marketplace install path in marketplace_add/install.rs. Trace where installed marketplace startup or upgrade handling is entered. Done means stale marketplace-upgrade-* entries in .staging are cleaned up after interrupted upgrades, with the existing janitor pattern applied without affecting current marketplace work.