Jonathon's AI Wiki

Claude Code Plugins and Marketplaces

25 min read

Source: ai-research (web research, 2026-04-11)

Plugins are the package layer for Claude Code — they bundle skills, agents, hooks, MCP servers, or LSP servers into installable units with version tracking and auto-updates. A plugin marketplace provides discovery, and enterprises can run private registries for governance. This is how the Claude Code ecosystem distributes and manages reusable tooling at scale.

What Plugins Are

  • A plugin is a package that can bundle any combination of (see also Cowork Plugins for the business-team plugin ecosystem):
    • Skills (procedural Markdown instructions)
    • Agents (autonomous worker configurations)
    • Hooks (event-driven automation triggers)
    • MCP servers (Model Context Protocol connectors to external systems)
    • LSP servers (Language Server Protocol for IDE-like intelligence)
  • Plugins have version numbers, changelogs, and support auto-updates
  • They are discovered and installed through marketplaces

Official Registry

  • claude-plugins-official registry: 101 plugins as of April 2026
    • 33 Anthropic-built plugins
    • 68 partner plugins from: GitHub, Playwright, Supabase, Figma, Vercel, and others
  • Auto-update is enabled by default for plugins from official Anthropic marketplaces

Installing Plugins

  • Browse the marketplace: /plugin marketplace add [publisher]/[name]
  • Install a plugin: /plugin install [name]
  • Two-step flow: first add from the marketplace, then install locally
  • Plugins configure themselves — MCP servers, skills, and hooks are registered automatically

Creating Your Own Marketplace

  • Define .claude-plugin/marketplace.json in your repository root
  • Host the repository on GitHub or GitLab
  • Other users can add your marketplace as a source: /plugin marketplace add [your-repo-url]
  • Useful for teams that want to share plugins internally without publishing to the official registry

Enterprise and Private Registries

  • Private registries available via LiteLLM AI Gateway for organizational governance
  • Admins control which plugins are available across the org
  • Supports approval workflows, audit trails, and version pinning
  • Available on Team and Enterprise plans

Plugin authoring (Weeks 13–14, 2026)

Two recent capabilities that significantly change what plugins can ship:

userConfig is now public (Week 13, v2.1.83+)

Plugins can declare userConfig in plugin.json to prompt for settings at enable time and store them with keychain-backed secrets (macOS Keychain, Windows Credential Manager, libsecret on Linux). Previously this was internal-only. Now any plugin can ask “what’s your API key?” / “what’s your default org?” on first install instead of forcing users to edit settings JSON.

Pattern: declare schema-validated config fields with secret: true for credentials. Claude Code prompts the user, validates, persists secrets to the OS keychain, and makes the values available to the plugin’s commands / hooks / agents at runtime.

Executables on PATH via bin/ (Week 14, v2.1.91+)

Drop an executable into a bin/ directory at the plugin root. Claude Code adds bin/ to the Bash tool’s PATH while the plugin is enabled. Claude can invoke the binary as a bare command — no absolute path or wrapper script. Closes the long-standing distribution gap where plugins shipped commands/agents/hooks but had to bundle CLI helpers as separate npm packages or rely on system-installed tools.

my-plugin/
├── .claude-plugin/
│   └── plugin.json
└── bin/
    └── my-tool       # invoked as `my-tool` from any Bash call

Combine with userConfig for a complete deliverable: plugin asks for credentials at enable time → binary in bin/ reads them via env / config → commands / hooks call the binary by name.

Plugin authoring (Weeks 16–17, 2026)

Two more capabilities that expand what plugins can ship:

Background watchers via monitors manifest key (Week 16, v2.1.105)

Plugins can now ship background watchers by declaring a top-level monitors key in plugin.json. Watchers auto-arm at session start or when the skill is invoked, running in the background and streaming events into the conversation. Use for: watching log files, polling CI, listening for file system changes — without requiring the user to start a separate /loop.

{
  "monitors": [
    {
      "name": "build-watcher",
      "command": "tail -f dist/build.log",
      "autoStart": true
    }
  ]
}

Plugins can ship custom themes (Week 17, v2.1.118)

Plugins can now include theme files that install into ~/.claude/themes/ when the plugin is enabled. Each theme picks a base preset (dark, light, etc.) and overrides only the color tokens it cares about. Useful for team/brand enforcement: ship one plugin that enforces a consistent color scheme across all developer terminals in an org.

New plugin management commands (Weeks 17–18)

CommandAddedBehavior
claude plugin tagW17 (v2.1.119+)Creates a release git tag for a plugin with version validation. Supports semantic versioning.
claude plugin prunev2.1.121Removes orphaned auto-installed plugin dependencies (packages installed as plugin dependencies but no longer referenced).

Plugin authoring (Week 19, 2026)

Load plugins from .zip archives and URLs (W19, v2.1.128+)

Two new ways to load plugins without installing via a marketplace — useful for testing before publishing, or distributing internal plugins from an artifact store:

  • claude --plugin-dir ./plugin.zip — --plugin-dir now accepts a .zip archive of a plugin directory in addition to a directory path
  • claude --plugin-url https://example.com/my-plugin.zip — new flag that fetches a plugin archive from any URL for the current session
# Load from local zip
claude --plugin-dir ./my-plugin.zip
 
# Load from URL
claude --plugin-url https://artifact-store.example.com/my-plugin.zip

Both approaches are session-scoped — the plugin is active for that session only, not installed permanently. Use claude plugin install for permanent installation.

Plugin management (v2.1.142–143, May 2026)

Root-level SKILL.md without skills/ subdirectory (v2.1.142)

Plugins with a root-level SKILL.md and no skills/ subdirectory are now automatically surfaced as a skill. Removes the boilerplate skills/<name>/SKILL.md nesting requirement for single-skill plugins. Minimum viable plugin structure is now:

my-plugin/
├── .claude-plugin/
│   └── plugin.json
└── SKILL.md    # surfaced directly as the plugin's skill

Plugin dependency enforcement (v2.1.143)

Claude Code now enforces plugin dependency chains on enable/disable:

  • claude plugin disable <name> — refuses when another enabled plugin depends on the target. Prints a copy-pasteable disable-chain command showing the full sequence needed to cleanly disable the dependency tree.
  • claude plugin enable <name> — force-enables transitive dependencies automatically. No more “plugin X not found” errors caused by a missing dependency.

Practical impact: multi-plugin workflows with shared dependencies (e.g., a base infrastructure plugin depended on by several feature plugins) now have explicit dependency tracking instead of silent breakage.

Projected context cost in /plugin browse pane (v2.1.143)

The /plugin marketplace browse view now shows per-turn and per-invocation token estimates for every listed plugin. Previously, cost visibility required running claude plugin details <name> separately. Now the discovery surface shows the cost picture before installation — useful for comparing similar plugins or budgeting token spend across a multi-plugin setup.

The /plugin details pane also shows LSP servers a plugin provides (v2.1.142), and claude plugin details <name> from the CLI matches the pane.

Plugin authoring (W22, v2.1.154-157, 2026)

.claude/skills auto-load without marketplace (v2.1.157)

Plugins placed in a .claude/skills/ directory within the project now auto-load without marketplace installation — no /plugin install step required. This closes the gap between the anthropics/skills-repo distribution model and local development: write a skill, drop it in .claude/skills/, and it activates on the next session (or immediately via /reload-skills from v2.1.152).

Combined with the v2.1.152 disallowed-tools frontmatter and /reload-skills command, the local skill authoring loop is now:

  1. Write skill file
  2. Drop in .claude/skills/<name>/SKILL.md (or use claude plugin init <name> to scaffold)
  3. Activates without marketplace or install step

This also confirms the CLAUDE_CODE_SYNC_SKILLS env var observed in v2.1.150 community signals: skills in .claude/skills/ are the primitive that env var syncs across worktrees.

claude plugin init <name> (v2.1.157)

New scaffold command creates a plugin template in the current directory. Same pattern as claude project init for projects. Lowers the minimum-viable-plugin creation from manually writing plugin.json + directory structure to a single command.

defaultEnabled: false in plugin manifest (v2.1.154)

Plugin authors can now declare defaultEnabled: false in plugin.json. The plugin installs but ships disabled; users enable individual features via /plugin. Useful for large multi-feature plugins where selective activation is preferable to all-or-nothing enable.

{
  "name": "my-plugin",
  "defaultEnabled": false
}

/plugin Discover tab pins directory-relevant plugins (v2.1.154)

The Discover tab surfaces plugins relevant to the current project’s language or stack at the top. Extension of the v2.1.143–145 marketplace-transparency arc (per-turn cost in v2.1.143, last-updated date in v2.1.144, full pre-install detail in v2.1.145, directory-relevance ranking in v2.1.154).

Community Registries

  • SkillsMP — 800,000+ agent skills searchable in one catalog
  • TokRepo — 500+ skills, MCP servers, and workflows curated for discovery
  • awesome-claude-skills on GitHub — 1,234+ skills with community ratings and reviews
  • Claude Skills Hub (claudeskills.info) — 658+ skills with a unique angle: foregrounds cross-vendor official collections (Anthropic 16, OpenAI 37, Microsoft 333, Google 11, Vercel 8, GitHub Copilot 324, WordPress) alongside curator bundles (Trail of Bits, Cybersecurity Skills 734+ MITRE-mapped, Everything Claude Code 86+, PM Skills 63). Featured on Product Hunt. Discovery surface — install via the underlying GitHub repo of any listed skill.
  • Community registries are not auto-updated; manual review and install is recommended

Canonical Anthropic Skill Repository

  • skills (124k stars) is technically a plugin marketplace too — /plugin marketplace add anthropics/skills registers it, and you install document-skills@anthropic-agent-skills or example-skills@anthropic-agent-skills from there. It’s the canonical reference repo for the Agent Skills standard and contains the formal spec/agent-skills-spec.md, a starter template/, and 17 example skills. Treat it as a sibling marketplace to claude-plugins-official rather than a community registry — Anthropic-run, but separate from the headline registry.

Third-party Frameworks (skills/orchestration on top of Claude Code)

Three large community projects ship as Claude Code distributions and represent distinct shapes of the same problem space — extending Claude Code with structured methodology, command surfaces, or multi-agent orchestration.

  • Superpowers (168k stars, MIT) — Auto-triggering skills bundle from Jesse Vincent / Prime Radiant. Distributed via the official claude-plugins-official marketplace (/plugin install superpowers@claude-plugins-official). Closed methodology, mandatory TDD, seven-phase workflow. Multi-agent across Claude Code, Codex, Cursor, Copilot, Gemini. Pick when you want one disciplined methodology applied uniformly without remembering command names.
  • SuperClaude Framework (22.5k stars, MIT) — Configurable surface area: 30 /sc:* slash commands, 20 agents, 7 behavioral modes, 8 MCP server integrations. Installed via pipx (pipx install superclaude && superclaude install). Not on the official marketplace; v5.0 will move to plugin distribution. Pick when you want à-la-carte commands and behavioral modes.
  • oh-my-claudecode (OMC) (30k stars, MIT) — Orchestration-first plugin + CLI from Yeachan Heo. 6 orchestration modes, ~19 specialized agents, magic keywords, HUD statusline, cross-model advisors (Codex / Gemini). Install via /plugin marketplace add https://github.com/Yeachan-Heo/oh-my-claudecode or npm. Pick when you want explicit multi-agent orchestration patterns.

These three frameworks coexist with native Agent Teams, Subagents, and Managed Agents — the third-party layer doesn’t replace the Anthropic primitives, it composes opinions on top of them.

Notable individual skills (2026-04-27 batch)

Cross-cutting skills installed independently of the larger frameworks/marketplaces above. All MIT, all installable via /plugin marketplace add <owner>/<repo> unless noted.

  • last30days-skill (mvanhorn, 24.2k stars) — Multi-platform research aggregator with v3 pre-research brain. Engagement-ranked output across Reddit / X / YouTube / TikTok / HN / Polymarket / GitHub / web. Multi-runtime: Claude Code, OpenClaw, Claude.ai .skill upload. Depends on yt-dlp for YouTube.
  • social-media-skills (Charlie Hills) (372 stars) — 16-skill voice-first content system for LinkedIn / Reels / YouTube / X / Substack. Sibling to Corey Haines’ Marketing Skills Bundle (breadth vs depth on social/newsletter).
  • birdclaw (steipete, 377 stars) — Local-first X/Twitter workspace + .agents/skills/birdclaw agent skill for AI access to tweets/DMs/likes/bookmarks via stable JSON. SQLite + FTS5 + JSONL Git backups.
  • ai-website-cloner-template (JCodesMore, 12.9k stars) — Next.js 16 reverse-engineering template. /clone-website <url> runs recon → spec → parallel git-worktree builders → QA. Multi-agent (Claude Code + 11 others).
  • yt-dlp (Unlicense) — Not a Claude skill. The canonical CLI YouTube/multi-site extractor that several skills depend on for transcripts, audio, and video. Surfaced here because skills above won’t work fully without it on $PATH.

Key Takeaways

  • Plugins solve the distribution and versioning problem that raw skill files cannot: auto-updates, dependency management, and discovery
  • The official registry (101 plugins) covers the most common integrations — check there first
  • Community registries (SkillsMP, TokRepo, awesome-claude-skills) have massive catalogs but require manual vetting
  • Enterprise teams should use LiteLLM AI Gateway for private registries with governance controls
  • Creating a marketplace is as simple as adding a marketplace.json to a Git repo

A marketplace as a team knowledge-distribution system (2026-08-25 addition)

The mechanics documented in this article are usually framed as “how to install someone else’s plugin.” A field playbook this week uses them for something different — distributing your own team’s skills, with the repo as the source of truth.

The problem it solves is stated crisply: “AI is very much single player.” Every teammate has their own setup, and a good skill built on one machine stays there. Two obvious workarounds fail for documented reasons:

  • Zip via Slack or email — creates duplicates that never receive upstream fixes and never send improvements back.
  • Google Drive / Dropbox / Obsidian sync — fails harder, because Claude reads only from its own skills directory. Making a synced folder work requires symlinks, which break the moment a non-technical teammate is involved.

The shape that works: one GitHub repository, skills grouped into folders by department, the repo registered as a marketplace, and each department folder exposed as its own plugin. The marketplace is the app store; the plugins are the apps. Department separation gives per-role access — the copywriter installs the copywriting plugin and never sees the finance skills.

Three operational details worth carrying into your own rollout:

  • Auto-update is load-bearing and it is per-installer. A teammate who does not enable it holds a frozen copy indefinitely, and the divergence is invisible until their output silently differs. Make it part of the install instructions and re-verify it.
  • Build it inside the GitHub organisation, not a personal account. The stated reason is ownership: skills an employee builds stay with the company when they leave.
  • On Claude Enterprise, use organisation plugins so non-technical staff never open a terminal or run a slash command.

The same source reports using the same repo as a plugin in both Claude Code and Codex, with the skills appearing in both. Other harnesses untested. Full playbook: Distributing Team Skills as a Plugin Marketplace.

A first-party community marketplace: anthropics/claude-plugins-community (2026-08-25)

Anthropic hosts a community plugin marketplace under its own GitHub organisation. The install pattern, as published:

claude plugin marketplace add anthropics/claude-plugins-community
claude plugin install eli5@claude-community

The eli5 plugin is the one surfaced this week — per Thariq (Anthropic), people at Anthropic use /eli5 to have a topic explained as if you know nothing about it, rendered as an HTML artifact with big pictures and very few words. Recorded here because the marketplace itself is the more durable fact: an Anthropic-org-hosted community registry is a distribution channel this article had not documented.

Try It

  1. Run /plugin marketplace in Claude Code to browse the official registry
  2. Install one plugin that addresses a current workflow gap (e.g., Playwright for browser testing, Figma for design handoff)
  3. Check community registries (SkillsMP, TokRepo) if the official registry does not have what you need
  4. For team use: create a private marketplace by adding .claude-plugin/marketplace.json to an internal repo
  5. On Enterprise plans: set up a LiteLLM AI Gateway private registry for org-wide plugin governance

Open Questions

  • What is in anthropics/claude-plugins-community besides eli5? The marketplace is named in a secondary source with one plugin. Its contents, contribution policy, and review process are not documented here.

  • Does plugin parity hold in Codex? A practitioner reports the same repo working as a plugin in both Claude Code and Codex. Whether hooks in particular carry over is untested.

  • How does plugin auto-update handle breaking changes? Is there a version pinning mechanism for production stability?

  • What is the review/approval process for partner plugins in the official registry?

  • Can plugins declare dependencies on other plugins?

Plugin authoring (2026-06-21, plugins-reference update)

Expanded hook event surface in plugins-reference

The official plugins-reference page now documents a comprehensive 31-event hooks table in its Hooks section. Compared to the 2026-05-10 snapshot, many events are newly documented. The full set is tracked in Claude Code Hooks; notable additions visible in plugins-reference:

New eventBehavior
UserPromptExpansionFires before prompt expansion resolves; can block
PermissionDeniedReturn {retry: true} to tell the model it may retry the denied action
PostToolUseFailureFires when a tool call completes with an error (distinct from success PostToolUse)
PostToolBatchFires after a batch of parallel tool calls all complete
NotificationFires when a notification is generated
SubagentStart / SubagentStopSubagent lifecycle pair
InstructionsLoadedFires when CLAUDE.md or instruction files are loaded
ConfigChangeFires when settings change during a session
WorktreeCreate / WorktreeRemoveGit worktree lifecycle pair
Elicitation / ElicitationResultElicitation request/response lifecycle pair

Plugin authors can register for any of these events in plugin.json hooks array:

{
  "hooks": [
    { "event": "PostToolUseFailure", "command": "bin/on-tool-error" },
    { "event": "SubagentStop", "command": "bin/subagent-cleanup" },
    { "event": "WorktreeCreate", "command": "bin/worktree-setup" }
  ]
}

See Claude Code Hooks for the full 31-event table, exit code conventions, and per-event payload schemas.

Plugin authoring (2026-07-26 watchlist sweep)

New content from ai-research/watchlist-snapshots/code-claude-com-docs-en-plugins-reference-2026-07-26.md:

v2.1.218 — Boolean frontmatter fields

In plugin skills and commands, Boolean frontmatter fields such as disable-model-invocation now accept yes, no, on, off, 1, and 0 in any letter case, in addition to true and false. Before v2.1.218, only true and false were recognized.

v2.1.212 — Uninstall fix for qualified names

When installed plugins from different marketplaces share a name, claude plugin uninstall plugin-name@marketplace-name now uninstalls only the plugin from the named marketplace. Before v2.1.212, the qualified form could match and uninstall the same-named plugin from a different marketplace.

workflows field in plugin.json manifest

Plugins can declare a workflows field to specify custom workflow script files or directories (replaces the default workflows/ directory). Same path-replace semantics as commands, agents, and outputStyles. The workflows/ folder at the plugin root is now listed in the file locations reference table alongside skills/, agents/, hooks/hooks.json, and .mcp.json.

{
  "workflows": "./custom/workflows/"
}

--keep-data flag for plugin uninstall

claude plugin uninstall <name> --keep-data preserves the plugin’s persistent data directory (${CLAUDE_PLUGIN_DATA}) when uninstalling from the last scope. By default, uninstalling from the last scope deletes the data directory. Use --keep-data when reinstalling after testing a new version.

channel scaffold option for plugin init --with

claude plugin init <name> --with channel now scaffolds a channel component folder. Full list of valid --with values: skills, agents, hooks, mcp, lsp, output-style, channel.

autoremove alias for plugin prune

claude plugin prune now has an alias: autoremove. Both commands remove auto-installed plugin dependencies that are no longer required by any installed plugin.

Plugin authoring (2026-07-16, security hardening)

${user_config.*} no longer substitutes into shell-parsed contexts (v2.1.207)

Two more plugin-config consumption paths that run through a shell stopped substituting ${user_config.*} values directly as of v2.1.207 — the same hardening shell-form plugin hooks got the same release:

  • Monitor command — can’t reference ${user_config.*}; Claude Code rejects the monitor with an error instead of substituting. Monitor processes don’t receive CLAUDE_PLUGIN_OPTION_<KEY> env vars either, so a monitor script must read the option from a config file it owns.
  • MCP headersHelper — same restriction; put the value in the server’s headers field instead (not shell-parsed), or have the helper script read it from its own environment or a config file.

Before v2.1.207, all three paths (monitor commands, MCP headersHelper, and shell-form hooks) substituted ${user_config.*} directly — a shell-injection-shaped gap for any config value with unescaped shell metacharacters.

pluginConfigs settings scope narrowed (v2.1.207)

Non-sensitive plugin config values, stored under the pluginConfigs key in settings.json, are now written to user settings and read back only from user settings, the --settings flag, and managed settings — entries in a project’s .claude/settings.json or .claude/settings.local.json are ignored. Before v2.1.207, Claude Code also read pluginConfigs from project and local settings, so a value committed to a repo’s .claude/settings.json applied automatically for anyone who cloned it.

Plugin distribution and managed settings (v2.1.221–v2.1.224, August 2026)

Source: ai-research/claude-code-docs-changelog-2026-08-07.md (official changelog, fetched 2026-08-07). Full narrative in What’s New — Week 32.

Archive plugin source (v2.1.224)

claude plugin install now accepts an archive source: install a plugin from a zip over HTTPS, with optional SHA-256 pinning. Neither git nor npm is required.

The SHA-256 pin is the load-bearing security detail. Without a pin, this is trust-on-first-use. With a pin, the install is content-addressed — the same integrity guarantee as a pinned npm package. Pair with the v2.1.223 "owner/*" wildcards below when setting org policy — the two features are designed to work together for supply-chain-governed enterprise plugin distribution.

Marketplace "owner/*" wildcard entries (v2.1.223)

strictKnownMarketplaces and blockedMarketplaces managed settings now accept "owner/*" wildcard entries — allow or block all marketplace repos under a GitHub org in one entry, instead of enumerating repos.

{
  "strictKnownMarketplaces": ["anthropic/*", "myorg/*"]
}

Useful for organizations that publish multiple plugin repositories and want a single governance rule across all of them.

Immediate activation on install (v2.1.221)

Plugins installed from /plugin now activate immediately when safe, instead of always requiring /reload-plugins. A forced reload is still needed for plugins that modify session-scope resources that cannot hot-swap.

claude plugin validate warnings (v2.1.221)

claude plugin validate now warns when a marketplace or plugin name would be rejected by Claude Desktop’s managed marketplace sync. Run before publishing a plugin to catch naming conflicts early.

Plugin authoring (2026-08-09 watchlist sweep)

New content from ai-research/watchlist-snapshots/code-claude-com-docs-en-plugins-reference-2026-08-09.md:

metadata field in plugin.json manifest (v2.1.222)

plugin.json now accepts a top-level metadata key: a free-form object that Claude Code passes through without interpretation or validation. Use it for distribution-tooling data — registry IDs, internal tracking, review timestamps — that your pipeline reads but the runtime ignores.

{
  "name": "my-plugin",
  "metadata": {
    "internalId": "ccplug-4f9a",
    "owner": "platform-team",
    "reviewedAt": "2026-08-01"
  }
}

Before v2.1.222, Claude Code treated metadata as an unrecognized field and silently ignored it. Safe to add to manifests when all consumers are on v2.1.222 or later; use "./" (below) compatibility note as the model for version-gating these additions.

"." shorthand for current directory in plugin install (v2.1.221)

claude plugin install "." now resolves to the current working directory. Before v2.1.221, the bare "." failed manifest validation and the plugin did not load. Use "./" if you need to support Claude Code versions older than v2.1.221.

Recent additions (2026-08-14 weekly sweep)

New plugin and marketplace changes in Claude Code v2.1.228–v2.1.233 (August 11–14, 2026), sourced from ai-research/claude-code-docs-changelog-2026-08-14.md:

  • Plugin marketplace command sources (v2.1.229). Marketplace plugins can now specify commandSources — additional directories or repos from which plugin commands are loaded. Lets a single plugin bundle commands from multiple source locations without flattening them into one directory.
  • GitLab marketplace support (v2.1.232). claude plugin install can now fetch plugins from GitLab repositories in addition to GitHub. The install URL format follows the same owner/repo convention on GitLab.
  • additionalMarketplaces / allowedMarketplaces aliases (v2.1.232). The additionalMarketplaces settings key (org and user scope) now has an alias allowedMarketplaces; both names are accepted interchangeably. The rename improves clarity for org admins writing governance policy: “allowed” better expresses an allowlist than “additional.”
  • /plugin install refreshes marketplace first (v2.1.232). Running /plugin install <name> now triggers a marketplace refresh before resolving the plugin name, so the install picks up newly published versions without requiring a manual /plugin marketplace refresh.
  • claude plugin validate bare skills check (v2.1.233). See CLI Reference entry above — validates .claude/skills/ directories for common structural mistakes that would prevent auto-loading.

Recent additions (2026-08-21 weekly sweep)

New plugin and marketplace changes in Claude Code v2.1.238 (August 20, 2026), sourced from ai-research/claude-code-docs-changelog-2026-08-21.md:

headersHelper for URL marketplace dynamic auth (v2.1.238)

Marketplace entries and url-type marketplace definitions can now specify a headersHelper field — the path to a local command that runs to mint HTTP headers for catalog and same-origin archive fetches. Use case: a private or org-internal marketplace that requires short-lived tokens (e.g. OAuth bearer tokens, signed JWTs) rather than static API keys stored in config.

Behavior and security:

  • A catalog entry’s headersHelper runs only when you install or update that plugin, after its command is shown; claude plugin install/update prompts [y/N] (or pass -y).
  • headersHelper from a project .mcp.json requires the folder’s trust dialog to have been accepted (also under claude -p).
  • Helpers from project/plugin scope run without inherited credential env vars, preventing credential leakage into the minting command. User-scope and managed-scope helpers run from the Claude config directory.
  • claude mcp list / claude mcp get now show disabled servers as ⊘ Disabled instead of connecting to them for a health check.

This enables enterprise teams to build authenticated plugin registries without embedding long-lived credentials in settings.json.

Source: ai-research/claude-code-docs-changelog-2026-08-21.md. Full detail in What’s New — Week 34.

Recent additions (2026-08-23 watchlist sweep)

New content from ai-research/watchlist-snapshots/code-claude-com-docs-en-plugins-reference-2026-08-23.md:

Synced plugin identity and priority changes (v2.1.239)

The identity format for plugins synced from claude.ai changed in v2.1.239:

  • Before v2.1.239: Synced plugins appeared in claude plugin list as <name>@inline.
  • As of v2.1.239: Synced plugins appear as <name>@synced.

Any existing references to @inline plugin identifiers in scripts, managed settings rules (allowedMarketplaces, blockedMarketplaces), or CI configuration must be updated to use @synced.

Priority change: User-installed plugins now take precedence over synced copies of the same plugin name. Before v2.1.239, a synced copy could shadow a locally-installed plugin with the same name — the synced version would win. The priority is now reversed: your explicitly-installed copy wins.

Visibility: claude plugin list now shows synced plugins on any machine where a synced session has downloaded them, not only on the machine where the sync was initiated. If you configured plugin sync on one machine and then open a synced session on another, the synced set appears in the listing on the second machine after the first download.

Synced plugins (via claude.ai) are distinct from marketplace-installed plugins (claude plugin install) — the synced set mirrors what you have enabled in the claude.ai UI; the installed set is per-machine.

Recent additions (2026-09-13 watchlist sweep)

New content from ai-research/watchlist-snapshots/code-claude-com-docs-en-plugins-reference-2026-09-13.md:

--json flag for claude plugin subcommands (v2.1.268+)

All five claude plugin subcommands now accept --json to return structured output instead of prose:

  • claude plugin install --json
  • claude plugin uninstall --json
  • claude plugin enable --json
  • claude plugin disable --json
  • claude plugin update --json

Output format:

{"command": "install", "outcome": "ok", "message": "...", "pluginId": "formatter@my-marketplace", "scope": "user"}

Fields: command, outcome (ok or error code), message (human-readable), pluginId (name + marketplace scope), scope (user or project), failureCode (present on failure). Enables scriptable plugin management in CI and automated setup flows.

--plugin-dir folder-of-plugins support (v2.1.265+)

--plugin-dir previously accepted a single plugin directory or .zip archive. As of v2.1.265+, it also accepts a directory containing multiple plugins — all plugins within the folder are loaded. Useful for monorepo setups or bootstrapping a full plugin set from a single parent directory.

claude plugin eval — quality testing for plugins (v2.1.269)

Added in Week 37 (September 7–11, 2026). Runs a plugin against a test suite and scores each case with and without the plugin, saving report.html to evals/results/ after every run.

Three commands:

  • claude plugin eval init — generates a test suite interactively. Claude asks what a good result looks like, proposes test cases and scoring checks, runs the suite once, and writes the files to evals/ in your plugin directory.
  • claude plugin eval . — runs all cases and prints a scored comparison table (score with plugin / score without / delta).
  • report.html — saved to evals/results/ with per-run detail beyond the terminal summary table.

Cost: every eval run is a real model call. A suite with 10 cases and a comparison baseline = 20 model calls minimum per run.

Relation to /skill-doctor: /skill-doctor (introduced in Week 36) shows usage data — which skills are loaded but rarely used. claude plugin eval shows quality data — whether a plugin actually improves outcomes. Both instruments are complementary; use /skill-doctor to decide what to keep and plugin eval to decide whether a plugin is working before shipping it.

# In your plugin's root directory:
claude plugin eval init     # interactive setup → writes evals/ directory
claude plugin eval .        # run suite, print table, write report.html

claude plugin install <plugin> --marketplace <source> (v2.1.275)

Install a plugin directly from a named marketplace source without setting that marketplace as default first:

claude plugin install formatter --marketplace my-registry

Useful when multiple marketplaces are configured and you want to target a specific one without changing the default.

Recent additions (2026-09-18 weekly sweep)

Sources: ai-research/claude-code-docs-whats-new-w37-2026-09-18.md, ai-research/claude-code-docs-changelog-2026-09-18.md.

  • claude plugin eval (v2.1.269) — see the ## claude plugin eval section above.
  • --marketplace <source> for install (v2.1.275) — targeted install from a named source; see section above.
  • claude.ai skills sync to terminal sessions (v2.1.275) — skills installed via the claude.ai web app now sync to CLI sessions on the same account. Previously, web-installed skills did not appear in the terminal.

Recent signals

[X signal — @claudeai 2026-05-27] Source: raw/x-account-claudeai-2059662933924123044.md (Marketplace partner-expansion post). The Claude Marketplace expanded with five new partner tools: @augmentcode, @boltdotnew, @coderabbitai, @hebbia, and @WeAreLegora. Per the post, enterprises can apply existing Anthropic spend commitments to these Claude-powered products — i.e., the Marketplace surface is hardening into a procurement layer where committed spend converts to partner-tool access without a new contract. URL: https://claude.com/platform/marketplace. Initial Marketplace launch was March 2026; this is the first material partner expansion the wiki has tracked.

Graph View

Backlinks