[BUG] temp_git_* clone-staging directories survive a successful plugin install and are never swept, even once marked with .orphaned_at

What's Wrong?

Differential first, because the plugin cache has several open issues and this is not any of them:

• Not #71074, #81217 or #82145 — all three are open, and all three are about version directories (<plugin>/<version>/) not being pruned. This report is about a different object: the temp_git_* clone-staging directory. The distinction is checkable — the string temp_git does not appear in any of those three issues, and repo-wide it appears in only three issues ever (#46566, #22296, #22461), all closed and locked.
• #82145 is the closest open relative and may share a root cause — it shows the documented 14-day orphan cleanup never firing because .in_use leases from dead PIDs pin the directory. If one sweep owns both object types, fixing that may fix this too. Offered as a hypothesis, not a claim: nothing in this report establishes they are the same code path.
• Prior art on this exact object, all closed by the inactivity bot and now locked: #46566 (the cleanest repro, and the report that first noted orphaned clones get walked by skill discovery and register bogus skill entries), #36245 (the most detailed: 301 stale temp_git_* directories, ~420 MB, alongside 1.2 GB of dead version cache), #47966 (proposed a claude plugin gc with --dry-run/--force/--keep-last N), and the #22160 → #22296 → #22461 cluster (a distinct root cause — clone hangs on private-repo auth with no timeout — that produces the same leftovers in the extreme: 22,000+ directories, ~32 GB, from a single clone stuck 53 hours).

The bug. claude plugin install / update stages each git clone in ~/.claude/plugins/cache/temp_git_<timestamp>_<hash>/ before moving it into the plugin's real versioned directory. On a successful install the staging directory is left behind and nothing later removes it. Notably it is not merely forgotten: these directories get marked — a .orphaned_at file containing an epoch-ms timestamp is written into them — so something in the product already classifies them as orphaned. The marking fires; the disposal never does.

One measured instance: five temp_git_* directories, 4.41 MB total, all partial clones of a single third-party marketplace plugin captured at different stop points, the oldest 13 days old at the time of measurement, each carrying a .orphaned_at marker. Two of the five contained the cloned repository's own CLAUDE.md. That is the same class of problem #46566 raised from the other end: content from an abandoned clone sitting inside the cache directory tree that the product itself walks.

What Should Happen?

The staging directory should be removed once its clone has been moved into place, and a directory already carrying a .orphaned_at marker should be disposed of rather than left marked indefinitely.

There is likely no new machinery needed: v2.1.210 already shipped a fix for "plugin cache writes leaving temp files behind on failure" (and for failing on locked-file renames on Windows and network filesystems). Extending that same clean-up-on-completion to the temp_git_* clone-staging path would plausibly close this.

Error Messages/Logs

N/A — nothing errors. It is silent disk accumulation plus stray repository content left inside the cache.

Steps to Reproduce

1. Install any plugin: /plugin install <name>@<marketplace>
2. ls ~/.claude/plugins/cache/ | grep temp_git — a temp_git_<timestamp>_<hash> directory is present.
3. Update the same plugin: a second staging directory appears and the first is still there.
4. find ~/.claude/plugins/cache -name '.orphaned_at' — leftover staging directories carry this marker, and keep carrying it indefinitely.

Honest note on this reporter's own re-check: at re-verification (2.1.236, seven actively-updated plugins, months of update history) this machine showed zero temp_git_* directories present — re-checked again on filing day, still zero — so the numbers above are from the earlier captured instance rather than a fresh reproduction on the current version. Every prior independent report (#36245, #46566, and the clone-hang cluster) reproduced it with its own figures, spanning February to April 2026, and none was ever answered.

Environment

• Claude Model: Not sure / Multiple models (plugin-manager mechanism, not model-dependent)
• Is this a regression? I don't know — reported repeatedly across four months, never described as having worked correctly
• Last Working Version: —
• Claude Code Version: 2.1.236 (claude update reports up to date on stable at filing time)
• Platform: CLI
• OS: Windows 11 Pro (10.0.26200)
• Terminal: Windows Terminal (PowerShell)

Additional Information

Deliberate scoping, so this is not read as re-litigating settled ground: the version-directory pruning problem is separately and currently tracked in #71074, #81217 and #82145 — all open — and this report takes no position on it. It is narrowed to the one object with no evidence of ever having been addressed: the temp_git_* clone-staging directories. The string temp_git appears nowhere in the CHANGELOG's full history through 2.1.251, and the five plugin-cache fixes that did ship over that period (2.1.142, 2.1.210, 2.1.228, 2.1.246, 2.1.247) each describe version-directory or general-write behaviour, never clone staging.

Pattern worth surfacing: across #36245, #46566, #47966 and the #22160/#22296/#22461 cluster, not one report on this object has ever received a reply from anyone with repo write access before the inactivity bot closed it.