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: #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:
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
- Does this belong in the SDK, its desktop consumer, or both?
- Is there existing/planned cache-lifecycle work to extend?
- 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.
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 acopilotexecutable and.copilot-cli.oksize marker. The versions were1.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:
Automatic deletion of all but the newest version is not the request: that would break intentional cross-app version coexistence.
Related context: #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:
copilot.exeit was launched from, breaking the GitHub Copilot app's bundled CLI copilot-cli#4728 (open): CLI auto-update overwriting a desktop app's version-pinned SDK-cache binary.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
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.