claude-code - 💡(How to fix) Fix [FEATURE] minReleaseAge setting for plugin auto-update (supply-chain quarantine) [1 participants]

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

Plugins ship code that auto-executes on next session: hooks, MCP servers, shell scripts. Auto-update for plugins (already requested in #51350) therefore has a fundamentally different threat model from auto-updating an npm dependency — a compromised plugin runs immediately under the user's full shell privileges the next time they start Claude Code.

The standard mitigation in package ecosystems is a release-age quarantine. npm has min-release-age, bun has minimumReleaseAge, pnpm has minimum-release-age, uv has UV_EXCLUDE_NEWER. They all enforce: "ignore versions published less than N days ago." This catches most opportunistic supply-chain attacks (typically caught and unpublished within hours-to-days) without blocking legitimate updates indefinitely.

Claude Code currently has no equivalent. Once auto-update lands (#51350), the next typosquat/compromise will be auto-installed within a session of being published.

Proposed Solution

Add a minReleaseAge field that gates auto-update by upstream publish age. Pairs cleanly with the auto-update setting in #51350:

{
  "marketplaces": {
    "claude-plugins-official": {
      "source": "...",
      "autoUpdate": true,
      "minReleaseAge": "7d"
    }
  }
}

Behavior:

• On marketplace refresh, compute publish age per plugin from the upstream commit/tag timestamp.
• Skip applying any version younger than minReleaseAge.
• Still surface "queued, applying in N days" to the user so the delay is visible, not invisible.

Defaults:

• For internal/Anthropic-published plugins (/plugins): 0 is fine — Anthropic controls them.
• For external plugins (/external_plugins): default to 7d.
• For user-added marketplaces: default to 7d, overrideable per-marketplace.

0 (or unset) preserves today's behavior for users who explicitly want it.

Alternative Solutions

• Manual gate — tell users to wait a week before running /plugin update. Doesn't compose with auto-update; relies on memory.
• Allowlist of trusted plugins — bypasses the issue but requires curation Anthropic likely doesn't want to take on.
• Reproducible builds + signing — better long-term answer but a much bigger lift; quarantine is the cheap interim.

Priority

Medium - Would be very helpful (especially as a precondition to enabling auto-update by default for external plugins)

Feature Category

Configuration and settings (plugins / supply-chain security)

Use Case Example

A team enables autoUpdate: true for a popular community plugin via #51350. A maintainer's account is compromised and a malicious version is published containing a hook that exfiltrates ~/.ssh/. Without quarantine, every team member on a stale-cache fix in the next session runs the malicious hook. With minReleaseAge: "7d", the bad version is detected and unpublished by community/Socket within ~24h before any auto-update fires; the team is unaffected.

This is exactly how min-release-age saved npm users from the recent chalk/debug and nx compromises.

Related

• #51350 — Enable marketplace auto-update through settings.json (the feature this builds on)
• #45051 — Marketplace serves oldest version instead of latest (separate bug, but partially mitigates auto-update risk today by sheer accident)
• #37252, #38271 — /plugin update cache staleness