Before You Install a Claude Code Plugin, Check What the Marketplace Actually Vetted

What a marketplace actually promises you

A Claude Code plugin is a bundle of skills, agents, hooks and MCP servers that installs and loads as one unit, and most of them come from a marketplace — a catalog that lists plugins and where to fetch each one. The question readers keep running into isn't whether to use plugins at all; it's whether adding one from a given marketplace is safe enough to do without reading the source first.

The honest answer from Anthropic's own documentation is that the marketplace's name doesn't answer that question. A marketplace's name tells you who publishes the catalog, not what each plugin in it does, so you're expected to review a plugin before installing it whichever marketplace it comes from. Some marketplace names are reserved for Anthropic's own marketplaces, and every other marketplace is third-party — but that split is about provenance of the catalog, not a guarantee about any single plugin's behavior.

Sources: Plugin security and trust - Claude Code Docs.

What you're actually granting when you install

A plugin you install can execute arbitrary code on your machine with your user privileges. That's the baseline fact to carry into any install decision, regardless of whether the marketplace is official or community-run.

Claude Code's permission rules and sandbox don't cover everything a plugin does. They cover the tool calls Claude makes — a call to one of the plugin's MCP tools, or a Bash command that runs an executable from the plugin's bin/, goes through your permission rules. But command hooks execute shell commands with your full user permissions, and Claude Code runs hooks and MCP servers outside the sandbox entirely. So a plugin's background processes and hook scripts aren't subject to the same approval prompts you'd see for an ordinary tool call.

Installing a plugin also enables it by default, unless the plugin's manifest or marketplace entry explicitly sets defaultEnabled to false and you haven't turned it on yourself. In other words, there's no separate 'install but stay off' state you get for free — you either decline the install or you're running it.

Sources: Plugin security and trust - Claude Code Docs.

The layers a skill has to clear before it runs

Before a plugin's skill can actually run, it has to be present at several layers: your settings have to list the marketplace as added and the plugin as enabled, and then the skill itself has to be loaded in your environment. A skill that's part of an enabled plugin behaves like any other skill once it's available — Claude uses it automatically when the task matches, without a separate prompt each time.

That automatic-use behavior is exactly why the install decision matters more than the per-call permission prompts that come later. By the time a skill is live, Claude is free to reach for it whenever it judges the task relevant; the review you didn't do at install time doesn't get a second chance at that point.

Sources: Plugins overview - Claude Code Docs, Agent Skills - Claude Platform Docs.

A worked example: adding a team plugin

Illustrative case: a five-person team wants a shared 'deployment-tools' plugin so everyone gets the same release checklist and a formatting skill. The lead sets this up through a project's .claude/settings.json, registering a marketplace and listing the two plugins they want active by default. Settings alone don't force the install — enabledPlugins activates the plugins automatically once a team member trusts the project folder, but each person can still disable it locally. A manual /plugin install adds a plugin regardless of what settings.json says, which is the path someone takes if they want a plugin outside the project's default set.

The part that actually matters for safety isn't the JSON, it's what happens to the marketplace repo afterward. Anthropic's plugins and marketplaces are highly trusted components that can execute arbitrary code, which is the documented reason to treat a one-person-can-merge policy on a plugin repo as a bad idea regardless of team size — a pull request, at least one approval, and a changelog entry before merging to main is the minimum discipline worth applying, and pinning to a tag instead of tracking a branch keeps an upstream change from silently landing in everyone's session overnight.

Sources: Manage Claude Code plugins for your organization - Claude Code Docs.

What org controls do and don't cover

If you're running this for a team rather than yourself, a few managed-settings levers exist, each solving a narrow problem. blockedMarketplaces lets an org name a marketplace source and refuse it outright. Inside an allowed marketplace, a single plugin can still be turned off by setting it to false in managed enabledPlugins — the allowlist matches marketplace sources, not individual plugins inside them, so blocking one bad plugin from an otherwise-fine marketplace needs this separate step.

None of this is per-user: every plugin key in managed settings applies to every user who receives that settings file, so targeting one team or group means a separate endpoint-managed settings file or gateway policy rather than a single shared one. And after the fact, OpenTelemetry events and the Analytics API tell an org what its fleet actually installed and ran — useful for catching a plugin that got added outside the reviewed path, but that's detection, not prevention.

Sources: All settings - Claude Code Docs, Manage Claude Code plugins for your organization - Claude Code Docs.

The checklist to run before you click install

Before adding a plugin, whether for yourself or a team, run through four checks: who hosts the marketplace (official reserved name or third-party, which changes nothing about per-plugin risk); what the plugin bundles (skills only, or also hooks and MCP servers that run outside the sandbox); whether it's pinned to a tag or tracking a branch; and whether your org needs it blocked at the marketplace level or just disabled as one entry inside an allowed one. None of these checks require advanced tooling — they're a matter of opening the plugin's source and the marketplace settings reference before you trust a catalog name to have done that work for you.

• Check the marketplace tier, but review the plugin itself either way — a reserved name doesn't vet individual plugins.
• Read what the plugin bundles: skills alone behave like sandboxed tool calls, but hooks and MCP servers run outside the sandbox with full user privileges.
• Pin team marketplaces to a tag and require PR review on the marketplace repo, not just on the plugins it lists.
• Use blockedMarketplaces for a whole untrusted source, and a false entry in managed enabledPlugins to drop one bad plugin from an otherwise-allowed marketplace.

Sources: Plugin security and trust - Claude Code Docs, All settings - Claude Code Docs.