Plugins and marketplaces: what installing actually adds

A plugin is a bundle, and the bundle is the point: "Plugins extend Claude Code with skills, agents, hooks, and MCP servers", and "Plugin marketplaces are catalogs that help you discover and install these extensions without building them yourself". One /plugin install can therefore add all four extension types in a single step, which is the convenience and the caution in the same sentence, because those four types have very different trust profiles.

This page is the product mechanics. The judgement question, what you are trusting when you install someone else's extension, has its own page, and applies to every plugin regardless of how smooth the install was.

The mechanics to know cold

The commands, the panel and the official catalog are in Anthropic's plugin documentation, and they change often enough that a copy here would only go stale. Three properties of the mechanism matter more than any command.

Enable, disable and uninstall are three different verbs. Disable keeps the plugin but stops loading it; uninstall removes it; "Removing a marketplace will uninstall any plugins you installed from it". The catalog is the plugin's lifeline as well as its shop.

Scope is a decision. A plugin can be personal or project-scoped, which is the difference between "my tool" and "my team's dependency": the same line slash commands cross when they enter the repo.

Updates differ by source. "Third-party and local development marketplaces have auto-update disabled by default"; for the official marketplace, assume the code you audited can change under you unless you disable auto-update. An auto-updating plugin is a standing supply-chain relationship rather than a one-time install.

Installed is not free

Every enabled plugin loads something at startup, and the product now says so itself: the Installed tab tracks usage so you can "find plugins that still add startup and context cost even though you no longer use them, then disable or uninstall them".

That makes plugin hygiene a context-budget task, not just a security one. The skills a plugin adds compete for the same routing attention as your own; its hooks run on your lifecycle events; its MCP servers hold connections you may have forgotten. Quarterly, open /plugin, read the Installed tab bottom-up (disabled and unused entries first) and delete what the usage data says you no longer use.

Organisations get levers here: managed plugin sets, and marketplace restriction, which trades individual freedom for a reviewable surface: the same trade as every other admin control, best made deliberately rather than by default.

What goes wrong

Counting the install as one decision. It was four: new skills, new agents, new hooks, new servers. The hook runs code on your events; the MCP server may hold credentials. Read the plugin's contents, not its description.

The forgotten integration. The Jira plugin from that one project, still enabled, still holding a connection, a year later. Unused grants are blast radius with no offsetting benefit.

Auto-update as silent re-install. The version you vetted is not the version you are running. For anything with hooks or servers in it, pin or re-review.

Debugging the wrong layer. Odd model behaviour, slow startup, a mysterious block — caused by a plugin's skill, hook, or server, and invisible until you think to check /plugin and its Errors tab.

Uninstalling by removing the marketplace. It works, and it takes every sibling plugin with it. Read the confirmation before agreeing.

How to check it worked

After any install, run the inventory: /plugin list, then look at what the plugin actually contributed — which skills now exist, which hooks fire, which servers connect. If you cannot name what an installed plugin added, you cannot notice when one of those pieces misbehaves. And once a quarter, the reverse check: anything the usage tracking calls unused gets disabled for a month, then uninstalled if nobody noticed.