Marketplace plugin updates load newly-pulled executable code under initial-install trust, with no re-consent or diff

Summary

Claude Code marketplace plugins are installed from git-backed marketplaces and cached locally under ~/.claude/plugins/. When a marketplace is refreshed, any new or changed executable primitives a plugin ships — hooks, .mcp.json server definitions, bin/ executables, LSP configs — are loaded and become eligible to execute under the trust the user granted at initial install. There is no re-consent step and no surfaced diff between the commit the user reviewed/consented to and the commit now running.

I want to explicitly distinguish this from the already-adjudicated "post-consent execution is out of scope" class of findings — e.g. Adversa AI's TrustFall, which Anthropic classified as working-as-designed on the grounds that the trust dialog is the security boundary (a trust model also mapped by Pluto Security's analysis of the Claude extension ecosystem). Those concern a single trust decision covering everything loaded thereafter. This is a different situation: the user's consent was made against commit A; the code now executing is commit B, which the user never saw. Install-time trust cannot be informed consent for code that did not exist at install time.

Current behavior

• Marketplace sources are materialized under ~/.claude/plugins/marketplaces/<name>/ — third-party marketplaces as a real git clone (live .git), the official anthropics/claude-plugins-official marketplace as an Anthropic-hosted snapshot tracked by a .gcs-sha (no local .git). Each installed plugin's files are copied into ~/.claude/plugins/cache/<marketplace>/<plugin>/<version>/ — the installPath recorded in ~/.claude/plugins/installed_plugins.json, alongside version, installedAt, lastUpdated, and the consented gitCommitSha.
• The official marketplace is refreshed on session start. Third-party auto-update is currently unreliable (see #44276, #26744, #36317), but the concern here applies whenever a refresh does occur.
• A refresh can advance a plugin from the commit the user installed to an arbitrary newer commit with no prompt — in place, without even a version bump. New or changed hooks, MCP server definitions, or bin/ scripts in that commit are loaded silently. Observed on my own install: an official-marketplace plugin's lastUpdated and gitCommitSha in installed_plugins.json advanced over a month after installedAt, while its version and cache directory were unchanged — executable content refreshed in place, with no re-consent.

Why this is distinct from the existing "working as designed" rationale

The stated boundary is that the trust dialog is the security checkpoint and everything loaded after consent is intentional. That reasoning is coherent for the initial install: the user saw (or could inspect) the plugin at commit A and accepted it. It does not extend to commit B.

A git pull is a code-supply event, not a configuration read. The correct analogy is a package manager: npm install foo@1.2.3 consents to 1.2.3, not to whatever the maintainer (or a repo/account compromise) pushes to that ref next. Auto-advancing an installed plugin's commit on session start is closer to silently re-running arbitrary postinstall scripts on every upstream push — a behavior the ecosystem has spent years hardening against.

Threat model

• Repo/account compromise: a malicious commit to a plugin's source is auto-pulled; a PreToolUse/SessionStart hook, MCP server, or bin/ script then executes with the developer's full local privileges on next session, with no indication.
• Maintainer turn / transfer: a previously-benign, widely-installed plugin that turns malicious (or is sold/transferred) reaches its entire installed base on the next pull, with no user re-review.
• This is the standard continuous-trust supply-chain vector, but with a direct execution surface (hooks/MCP/bin) rather than merely importable library code.

Proposed behavior

Any one of these would close the gap; listed in increasing order of user friction:

1. Diff-and-confirm on update: if the new commit adds or changes any executable primitive (hooks, .mcp.json, bin/, LSP config), surface a diff of exactly those changes and require explicit confirmation before loading. Pure content changes (skill/prompt markdown) could update silently or with a lighter notice.
2. Pin by default: pin installed plugins to the consented gitCommitSha; treat advancing the pin as an explicit plugin update action rather than an automatic session-start side effect.
3. Minimum viable: a per-marketplace / per-plugin autoUpdate: false setting, with a managed-settings equivalent, so the current behavior is opt-in rather than default.

Prior art / references

• Adversa AI, TrustFall — post-consent MCP auto-launch; classified by Anthropic as outside its threat model.
• Pluto Security, "Skills, Connectors, Plugins, Oh My" — maps the Claude extension trust radius: a single plugin install activates skills, MCP servers, hooks, and binaries under one consent.
• CVE-2025-59536 / CVE-2026-21852 / CVE-2026-33068 — the pre-consent execution class (patched). Cited to contrast, not equate: this request is specifically about the post-install update path.
• #44276 / #26744 / #36317 — existing reports that third-party plugin updates are unreliable; the functional inverse of this request, and evidence that the update path is already being actively worked on.

Environment

• Claude Code: 2.1.199 (VS Code extension anthropic.claude-code; no standalone CLI installed)
• OS: Linux (Ubuntu)
• Plugins: user-scope, from the official and third-party GitHub-backed marketplaces

---

Disclosure: this report was drafted with AI assistance and reviewed and edited by me before submission.