Feature request: inspect and safely prune SDK-managed CLI caches

Feature request: inspect and safely prune SDK-managed CLI caches

Problem

The SDK intentionally stores CLI versions side by side for compatibility. Across application updates, historical copies can accumulate, but I could not find a supported cache inspection/pruning workflow or retention control in the examined implementations.

On one macOS 26.7 arm64 machine, a read-only inspection found 9 cached CLI versions totaling 1.353 GB under ~/Library/Caches/github-copilot-sdk/cli/. Each contained a copilot executable and .copilot-cli.ok size marker. The versions were 1.0.69-2, 1.0.71, 1.0.71-2, 1.0.73, 1.0.78-2, 1.0.79-5, 1.0.80, 1.0.83, 1.0.84-5.

Two running processes from GitHub Copilot.app used 1.0.84-5. This does not establish that the eight other versions are unneeded; they may serve inactive consumers. No cache entries were deleted.

Implementation context

The Rust bundled CLI installer lazily extracts into a version-specific directory and reuses an existing valid copy. The observed marker/layout matches this mechanism. I did not establish the source revision used by each historical binary, or which app created every copy.

Requested capability

Would maintainers consider a documented inspection/pruning API or utility, or identify the existing supported cleanup mechanism if I missed it?

Suggested starting scope:

• Enumerate cached versions and sizes.
• Explicit opt-in pruning with a dry-run mode and caller-specified keep versions.
• Safeguards for in-use versions and concurrent installation.
• Clear offline/re-extraction behavior per SDK provisioning mode.
• Documentation explaining ownership between shared SDK caches and consumer applications.

Automatic deletion of all but the newest version is not the request: that would break intentional cross-app version coexistence.

Related context: https://github.com/github/copilot-sdk/issues/2524 tracks v2 runtime discovery, acquisition and embedding. This request concerns historical-version cache lifecycle rather than replacing that work.

Additional related work found in a follow-up search:

• https://github.com/github/copilot-sdk/pull/1480 (merged): recovery when a build-time-extracted cache binary disappears.
• https://github.com/github/copilot-cli/issues/4728 (open): CLI auto-update overwriting a desktop app's version-pinned SDK-cache binary.
• The standalone CLI changelog already documents old auto-update package cleanup (0.0.388 and 1.0.40). This request is specifically about the SDK-managed versioned extraction cache, not that separate package cache.

No direct duplicate was found in targeted public issue/PR and Discussion searches; this is not a claim that none exists.

Questions before a PR

1. Does this belong in the SDK, its desktop consumer, or both?
2. Is there existing/planned cache-lifecycle work to extend?
3. Which languages and cache layouts should a first contribution cover?

I can contribute a scoped implementation and tests once the intended design and ownership are agreed.

Reproduction status

This report is backed by a measured local cache and process ancestry. A controlled reproduction using sequential bundled CLI versions in an isolated cache is proposed but has not yet been executed. File timestamps were not treated as reliable last-use records.