Summary
When a marketplace defines plugins, there is no way to signal that installed plugins should be kept up to date automatically. Users must manually run copilot plugin update <name> to get the latest version, which means teams shipping plugin updates have no guarantee consumers are on the current version.
Proposal
Add an optional autoUpdate flag at the marketplace level in marketplace.json:
{
"name": "my-org",
"metadata": {
"autoUpdate": true
},
"plugins": [...]
}
When autoUpdate is true, the CLI would check for plugin updates on startup (or periodically, e.g. once per day) and pull the latest for all installed plugins from that marketplace.
Why marketplace-level rather than per-plugin?
- Simpler mental model — org admins opt in once for all their plugins
- Avoids inconsistent states where some plugins are stale and others are fresh
- Marketplace owners are already the trust boundary for plugin distribution
Considerations
- Startup latency: A background check + async pull would avoid blocking the CLI. Could also be throttled to once per 24h with a local timestamp cache.
- Opt-in: This should be opt-in (default
false) so existing marketplaces are unaffected.
- Offline/CI: Should gracefully no-op if the network is unavailable.
Use case
We maintain an internal org marketplace with skills that evolve frequently (e.g., Confluence page generators, ticket readiness checks). When we ship an update, we currently have to Slack the team and ask everyone to manually run the update command. An auto-update flag would remove that friction entirely.
Alternatives considered
- Shell profile hooks (
~/.zshrc) — brittle, not portable, hard to enforce across a team
- Cron jobs — requires per-machine setup, easy to forget
copilot plugin update --all on startup — would work but is less granular than marketplace-level control
Summary
When a marketplace defines plugins, there is no way to signal that installed plugins should be kept up to date automatically. Users must manually run
copilot plugin update <name>to get the latest version, which means teams shipping plugin updates have no guarantee consumers are on the current version.Proposal
Add an optional
autoUpdateflag at the marketplace level inmarketplace.json:{ "name": "my-org", "metadata": { "autoUpdate": true }, "plugins": [...] }When
autoUpdateistrue, the CLI would check for plugin updates on startup (or periodically, e.g. once per day) and pull the latest for all installed plugins from that marketplace.Why marketplace-level rather than per-plugin?
Considerations
false) so existing marketplaces are unaffected.Use case
We maintain an internal org marketplace with skills that evolve frequently (e.g., Confluence page generators, ticket readiness checks). When we ship an update, we currently have to Slack the team and ask everyone to manually run the update command. An auto-update flag would remove that friction entirely.
Alternatives considered
~/.zshrc) — brittle, not portable, hard to enforce across a teamcopilot plugin update --allon startup — would work but is less granular than marketplace-level control