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)
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 45/100
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
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
- Configure an enterprise-managed plugin containing a
hooks.json, viamanaged-settings.json(extraKnownMarketplaces+enabledPlugins). Confirm it installs and its hooks fire (e.g. a hook that appends to a log onpreToolUse). - 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. - Tamper with the plugin in any of the ways below.
- Start a new Copilot CLI session (full relaunch) and run a tool.
Actual behavior
- Editing a managed plugin's
hooks.jsonis 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_shainconfig.jsondoes 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.jsonvia.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
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de github/copilot-cli
-
triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
github/copilot-cli#4932 ·
-
triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
github/copilot-cli#4909 ·
-
triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
github/copilot-cli#4906 ·
-
triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
github/copilot-cli#4848 ·
-
area:agents area:mcp
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
github/copilot-cli#4729 ·
Todos los issues de github/copilot-cli
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
bug easy help wanted
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
lacs-project/sysknife#503 ·
-
help wanted kind/documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
liquidmetal-dev/flintlock#1239 ·