[FEATURE] Enable marketplace auto-update through settings.json
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
Organizations can enforce plugin installation centrally by shipping managed settings.json (e.g. via MDM or an enterprise-scoped config), but there is no corresponding way to enable marketplace auto-update from config. Auto-update for a marketplace can only be toggled per-user through the /plugin TUI.
This means a central admin can guarantee everyone has a given marketplace installed, but cannot guarantee anyone receives updates to it. Each user has to individually remember to open the TUI and flip the auto-update toggle, and there's no way to verify or enforce that they did.
This was previously reported in #17815 (closed as stale by the bot, now locked). The original request was from a marketplace author with essentially the same need.
Proposed Solution
Add a per-marketplace settings.json field alongside the existing install config:
{
"marketplaces": {
"my-marketplace": {
"source": "github:org/my-marketplace",
"autoUpdate": true
}
}
}
Per-marketplace (rather than a single global flag) lets different orgs apply different policies per source — for example, auto-updating trusted internal marketplaces while pinning third-party ones.
The setting should behave the same as the TUI toggle: the marketplace is refreshed on session start, and plugin changes take effect after a Claude Code restart (as confirmed in #17815's thread).
When the setting is present in managed/enterprise settings, it should take precedence over the user-level toggle, so admins can enforce the policy.
Alternative Solutions
- Currently: force-install the marketplace via
settings.json, then tell every user to open/pluginand flip auto-update. Error-prone and impossible to verify. - Shipping a hook that calls
claude plugin marketplace updateon session start — clunky, requires every user to install it, and the plugin/marketplace update CLI isn't really designed for this.
Priority
Medium - Would be very helpful
Feature Category
Configuration and settings
Use Case Example
An engineering org maintains an internal marketplace of Claude Code skills tailored to their stack. Typical rollout:
- A platform engineer publishes a new version of a skill (e.g. a bug fix, or a brand-new skill for a common workflow).
- The org wants every engineer to pick it up on their next Claude Code session, without any individual action.
- Today, the org can ship a managed
settings.jsonthat installs the marketplace, but engineers who never opened the TUI to enable auto-update stay pinned to whatever version they installed originally. - With this feature, the same managed
settings.jsoncould setautoUpdate: true, and every engineer would pick up new skills automatically on the next session start.
Showing cached comments. Read the full discussion on GitHub ↗
4 Comments
Found 2 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Reading this issue you'd assume auto-update works and just needs config exposure. It mostly doesn't.
Single-user machine, Claude Code itself current, here's what I found today:
| marketplace | local HEAD |
|---|---|
| impeccable | 127 commits behind origin/main |
| claude-hud | 85 behind |
| openai-codex | 2 behind |
| qmd | 1 behind |
impeccable sat at late January while upstream moved. I noticed only because a different plugin (claude-mem) shipped a buggy Read hook in v12.1.1 and the fix had been out for 8 releases / 10 days before I saw it. I spent an hour debugging why my
Readcalls kept getting truncated tolimit: 1before realizing claude-mem had already shipped the fix and I was just pinned to the broken version.Running
claude plugin marketplace updatefollowed byclaude plugin update <each>from the CLI caught everything up in under a minute. The explicit CLI doesgit pull. Session-start auto-sync seems togit fetchonly. That's #41885.Three layers:
Interim: I have a launchd job running those two CLI commands nightly. Writing cron around session-start is the signal, the working path currently lives outside the app.
Oh, I didn't realize it was this bad. We just launched our internal marketplace of plugins, and I was kind of wondering why we weren't seeing updates to some of the installed plugins... 🤔
This is a needed feature.