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)
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
Research direction
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.
Written by the indexing model from the issue text.
Description
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
- Dominant language
- Shell
- Stars
- 11.2k
- Forks
- 1.9k
- Avg merge
- 14h 16m
- Merged PRs (30d)
- 6
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from github/copilot-cli
-
triage
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
github/copilot-cli#4932 ·
-
triage
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
github/copilot-cli#4909 ·
-
triage
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
github/copilot-cli#4906 ·
-
triage
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
github/copilot-cli#4848 ·
-
area:agents area:mcp
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
github/copilot-cli#4729 ·
All issues in github/copilot-cli
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
elastic/gradle-plugins#156 ·
-
Priority/High ready-for-agent Severity/Major Type/Bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
comp/cli P3 type/docs
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
NousResearch/hermes-agent#119756 · 1 comment ·
-
comp: build/pipeline type: bug version: current (v17+)
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
angular/angularfire#3766 ·
-
out-of-date
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
CachyOS/CachyOS-PKGBUILDS#1903 ·