Git-source plugins re-clone at every startup despite cache hits, and the temp clone dirs leak into the cache root

What's Wrong?

Git-source plugins (github / git / git-subdir marketplace sources) trigger a clone to a temporary directory on every Claude Code startup to resolve the current version, even when the SHA-versioned plugin cache already contains that exact version. Two symptoms:

1. Redundant network + disk work per startup. With a dozen git-source plugins, each startup creates a fresh set of temp_git_* / temp_subdir_*.clone directories to learn the remote SHA, then (on cache hit) loads from the existing cache anyway. Historical profiling on my setup (2026-02, 15 URL-source plugins) measured ~10.6s of a ~15s startup spent on these clones at 400–1500ms each; I have not re-profiled on current versions, but the clone-to-temp flow demonstrably still runs (see evidence).

1. The temp clone directories leak into the cache root. ~/.claude/plugins/cache/ on this machine currently holds 27 leftover temp_git_* / temp_subdir_*.clone directories from three startups two days ago. They are eventually collected (none older than 8 days survive), but they should be removed when startup finishes with them, not linger for days alongside the versioned cache entries.

What Should Happen?

• Resolve the remote SHA with git ls-remote (~50ms) instead of a full clone, and only clone when the SHA is not already cached. For git-subdir sources the sparse clone helps, but ls-remote would skip the clone entirely on the (common) cache-hit path.
• Delete each temp clone directory as soon as the version check that created it completes, regardless of hit/miss.
• Optionally: a configurable freshness window (trust the cached version for N seconds without any network check) would help people who cycle sessions frequently during plugin development.

Error Messages/Logs

Cache-root listing two days after the startups that created these (Claude Code 2.1.206):

$ ls ~/.claude/plugins/cache | grep -c '^temp_'
27
$ stat -f '%Sm %N' ~/.claude/plugins/cache/temp_* | tail -1
Jul  7 10:20:46 2026 .../cache/temp_subdir_1783437646963_8gfy3o.clone

The three timestamp clusters correspond to three session startups; each cluster has 11–12 temp dirs, matching the number of git-source plugins in the marketplace.

Steps to Reproduce

1. Add a marketplace with ~10 plugins from github / git-subdir sources (no version field in plugin.json, so SHA-based versioning).
2. Start Claude Code, let plugins load, exit.
3. Start Claude Code again with no upstream changes: the same clone-to-temp flow runs for every plugin despite every SHA already being cached.
4. ls ~/.claude/plugins/cache/ — temp_git_* / temp_subdir_*.clone directories from completed startups remain.

Claude Model

n/a (startup, before any model use)

Is this a regression?

No — long-standing behavior (observed since at least 2026-02); the temp-dir lingering is newly observed on 2.1.x.

Environment

• Claude Code 2.1.206
• macOS (Darwin 25.5.0)
• 13 git-source plugins from a personal marketplace (git-subdir sources), plus 3 other marketplaces