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

Managed plugins are never re-synced from the server after install — local edits/deletions to plugin content are neither detected nor corrected (enforcement silently defeatable)

Abierto
#4,933 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
cli, shell
Área
cli, security

Línea de trabajo

The issue describes a security flaw in managed plugin syncing. Look at the plugin installation and sync logic, likely in the code handling managed-settings.json and the marketplace cache. The paths mentioned are ~/.copilot/installed-plugins/ and ~/Library/Caches/copilot/marketplaces/. Start by finding where plugins are installed and validated on session start. Check the source_sha calculation and the re-sync guard condition from issue #4039. 'Done' means the system detects content mismatches and re-fetches from the source, not the cache.

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

Descripción

triage
Describe the bug

Once an enterprise-managed plugin (delivered via extraKnownMarketplaces + enabledPlugins in managed-settings.json) is installed, Copilot CLI never re-validates or re-syncs its content from the marketplace/server. The on-disk plugin files are user-writable and unsigned, and no session start, periodic refresh, or re-login re-fetches them from the source. The enabled flag in config.json is policy-locked, but the plugin content (e.g. its hooks.json) is not protected at all.

As a result, a developer can neutralize a managed plugin's hooks — with no elevated privileges and no error surfaced — by editing the hook file, deleting it, or repointing it. Nothing built into Copilot detects the change or restores the server's version.

For teams using managed plugins as a governance / policy-enforcement mechanism, this means the managed-plugin persistence guarantee does not hold: policy-pinned hooks can be silently and permanently disabled locally.

Steps to reproduce
  1. Configure an enterprise-managed plugin containing a hooks.json, via managed-settings.json (extraKnownMarketplaces + enabledPlugins). Confirm it installs and its hooks fire (e.g. a hook that appends to a log on preToolUse).
  2. Confirm it is synced on disk under ~/.copilot/installed-plugins/<marketplace>/<plugin>/ (and mirrored in the marketplace cache under ~/Library/Caches/copilot/marketplaces/<slug>/), and that the log records hook events.
  3. Tamper with the plugin in any of the ways below.
  4. Start a new Copilot CLI session (full relaunch) and run a tool.
Actual behavior
  • Editing a managed plugin's hooks.json is never detected or corrected — the tampered content runs on every subsequent launch, with no error.
  • Relaunching, signing out and back in, and the periodic refresh all leave tampered content in place; none re-fetch from the source.
  • source_sha in config.json does not guard integrity — it is recomputed from whatever is on disk and re-stamped to match the tampered content.
  • Deleting the whole plugin folder does trigger a re-sync, but it restores from the local (user-writable) marketplace cache, so tampered content is re-instated rather than corrected.
  • Deleting only hooks.json (leaving the folder in place) is not re-synced at all — the plugin still shows installed/enabled, but its hooks never run again and are never restored.

This looks related to the "Re-sync managed plugins when their cache is missing or empty" behavior (see #4039): the re-sync guard keys on whether the cache directory exists and is non-empty, rather than on whether the content matches the source — so any tamper that leaves a non-empty directory (an edit, or a single-file delete) is neither detected nor corrected, and the one guard that does fire restores from a local cache rather than re-fetching from the source.

Expected behavior

At session start (and ideally on the documented periodic refresh), Copilot should verify each managed plugin's on-disk content against the version declared by the marketplace/policy — e.g. a manifest or content hash fetched from the source, not the recomputed local one — and re-fetch from the source on any mismatch. This should cover edits and partial deletions, not just a missing/empty folder, and should never treat the local cache as authoritative for a policy-pinned plugin. If restoration is not possible, the tampered/incomplete state should surface as an error rather than silently running tampered content or reporting "no hooks."

Environment
  • Copilot CLI version: 1.0.87
  • OS: macOS
  • Delivery: enterprise managed-settings.json via .github-private (extraKnownMarketplaces + enabledPlugins)
  • License: Copilot Business / Enterprise
Lenguaje dominante
Shell
Estrellas
11.2k
Forks
1.9k
Merge medio
14 h 16 min
PR fusionados (30 d)
6

Guía de contribución

Abrir la guía de contribución

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-cli

Todos los issues de github/copilot-cli

Issues similares

Más issues de Shell/Bash

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.