Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#2,722 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
rust
Área
cli, tooling

Línea de trabajo

Start with rust/src/embeddedcli.rs to understand the versioned extraction cache, then review issue #2524 and PR #1480 for related lifecycle context. A contribution is ready to scope only after maintainers decide ownership, supported languages and layouts, and safeguards; done would be agreed implementation, tests, and documentation.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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:

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.

Lenguaje dominante
TypeScript
Estrellas
10.5k
Forks
1.5k
Merge medio
1 d 7 h
PR fusionados (30 d)
98

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de github/copilot-sdk

Todos los issues de github/copilot-sdk

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.