Security1 publisher2 min readPublished
GitHub gives org and MDM policy the final word on Copilot CLI plugins
The Copilot CLI plugin reference now puts organization and MDM policy above local toggles. The same rewrite retires the flags and JSON shape that existing plugin scripts were built on.
The Watch · Security desk
What happened
- An organization or MDM managed policy can pin a plugin or marketplace through enabledPlugins or extraKnownMarketplaces. For that entry the managed value wins; it cannot be enabled, disabled or repointed locally.
- In the /plugin dashboard those entries carry a Managed badge. The dashboard refuses any toggle that conflicts with the managed value.
- When the current repository's enabledPlugins overlay decides a plugin's activation, copilot plugin enable and disable are rejected, and the error names the settings file that actually controls it.
- The cross-kind --kind, --scope, --mcp and --skill flags are removed, with copilot mcp, copilot skill, copilot instruction and copilot lsp taking over those jobs.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- capability Allowlisting agent plugins and marketplaces is now enforceable from org or MDM policy. A developer who tries to override a pinned entry gets an error.
- constraint The override works entry by entry, so central control is only as wide as the list an administrator maintains and keeps current.
- cost Wrappers, dashboards and CI checks built on the retired syntax and the old JSON object need rewriting before the CLI is upgraded. That work sits with whoever owns the tooling.
- exposure Plugins from the two built-in first-party marketplaces pull new code at the start of every session in a trusted working directory. Upstream changes land on developer machines with no review step in the documented flow.
For marketplaces that share a name, the reference sets three tiers: a built-in first-party marketplace wins, then a managed entry, then the user's own [14]. The managed entry replaces the whole same-named user entry, so one that omits `"autoUpdate": true` removes a developer's existing opt-in [14]. Built-in default marketplaces ship with the runtime and cannot be removed at all [15].
Session-start updates are controlled from user settings and managed settings. First-party auto-update goes off by setting `autoUpdate` to false or exporting `COPILOT_AUTO_UPDATE=false`, and CI skips it by default [11]. A marketplace a developer added can opt in for interactive and `-p` sessions; SDK and server sessions do not auto-update [12]. The opt-in is honored from user settings or from managed settings, while a repository-level `autoUpdate` setting is accepted and ignored [13]. A repository can set activation; the update decision stays in user and managed settings [4].
Path-sourced plugins in a directory-source marketplace load live from their real directory, and an edit takes effect on `/restart` or in a new session with no `copilot plugin update` [9]. When managed policy pins that marketplace, the pin fixes which entry loads. The contents of the directory behind it can still change between sessions [2].
On the machine-readable side, `copilot plugin list --json` emits a flat array of plugins in place of the `{ plugins, errors }` object [5], and each row is `{ name, marketplace?, version?, enabled, source, installedFrom? }` [6]. The documented output has no `.plugins` key and no `.errors` key for a script to read [1]. The reference page does not give a date or a CLI version for the split.
Two other kinds install through their own commands. MCP servers install from a policy-configured registry that requires authentication and interactive secret entry, added through the Online view of the `/mcp` dashboard or with `copilot mcp add`; `copilot plugin install` does not do it [7]. `copilot skill add` installs a skill, and the page says that is not a plugin install and does not go through a marketplace [8].
Manifest review splits the same way. A plugin opts into the closed Agent Plugins 1.0 schema only by carrying the exact `$schema` value `https://agent-plugins.org/schemas/1.0.0/plugin.schema.json`, and a manifest without it loads in the legacy format as before [17].
What to watch
- Whether a policy key appears that blocks any plugin absent from enabledPlugins, and not only the entries an admin has pinned.
- Whether managed settings gain keys for skill and language-server installs, which currently arrive outside the marketplace path.
- Whether GitHub dates the command split or ties it to a CLI version teams can pin in CI.