[FEATURE] Enable marketplace auto-update through settings.json

Status Fixed / completed
Maintainer reply None cached
Activity 5 comments · opened Apr 20, 2026 · closed Aug 17, 2026

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 /plugin and flip auto-update. Error-prone and impossible to verify.
  • Shipping a hook that calls claude plugin marketplace update on 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:

  1. A platform engineer publishes a new version of a skill (e.g. a bug fix, or a brand-new skill for a common workflow).
  2. The org wants every engineer to pick it up on their next Claude Code session, without any individual action.
  3. Today, the org can ship a managed settings.json that installs the marketplace, but engineers who never opened the TUI to enable auto-update stay pinned to whatever version they installed originally.
  4. With this feature, the same managed settings.json could set autoUpdate: true, and every engineer would pick up new skills automatically on the next session start.

View original on GitHub ↗

4 Comments

github-actions[bot] · 4 months ago

Found 2 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/10265
  2. https://github.com/anthropics/claude-code/issues/17815

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

creatornader · 4 months ago

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 Read calls kept getting truncated to limit: 1 before realizing claude-mem had already shipped the fix and I was just pinned to the broken version.

Running claude plugin marketplace update followed by claude plugin update <each> from the CLI caught everything up in under a minute. The explicit CLI does git pull. Session-start auto-sync seems to git fetch only. That's #41885.

Three layers:

  • Mechanism. Session-start auto-sync fetches without pulling (#41885). The TUI toggle looks live but doesn't deliver updates. This has to be fixed first or every layer above is cosmetic.
  • Defaults. Per-marketplace opt-in asks users to re-decide for every marketplace they install. The thing most users mean by "auto-update" is global: everything stays current unless specifically pinned. Flip the default.
  • Config surface. A settings.json knob is the right shape for declarative control, but if it ships per-marketplace-only on top of #41885, it'll read as another knob that doesn't do what the name suggests.

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.

LandonSchropp · 4 months ago

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... 🤔

nikhilsitaram · 3 months ago

This is a needed feature.

Showing cached comments. Read the full discussion on GitHub ↗