Claude Code Plugins: How to Install Them and Which to Trust

To install a Claude Code plugin, run /plugin in a session, find it on the Discover tab and choose a scope; or type /plugin install <name>@<marketplace> if you already know it. Anthropic’s official marketplace is added for you the first time you start an interactive session. Anything else, including a plugin on GitHub, comes in by adding its marketplace first with /plugin marketplace add owner/repo. Before you install, remember what you are agreeing to: a plugin’s hooks and MCP servers run on your machine as you. Read them, keep the ones you use, and disable the rest.

A plugin is a package of skills, subagents, hooks and MCP servers that installs as one unit. How those pieces compare, and when to build your own plugin, is in Claude Code plugins vs skills vs subagents. This article is about getting other people’s plugins in, keeping them current, and deciding which ones deserve to be there.

Where plugins come from

Plugins are listed in marketplaces: catalogues, each a repository or folder with a .claude-plugin/marketplace.json file that says where to fetch every plugin. Anthropic’s marketplaces page↗ (opens in a new tab) describes three general ones:

• Official, named claude-plugins-official: plugins Anthropic maintains, such as commit-commands, code-review and feature-dev, plus plugins from partners and other authors. Added automatically.
• Community, named claude-community: third-party plugins their authors submitted. Add it with /plugin marketplace add anthropics/claude-plugins-community.
• Demo, named claude-code-plugins, from anthropics/claude-code: a few example plugins, most of them also in the official marketplace. Older tutorials tell you to add it; you usually do not need to.

Everything else is third-party: a vendor’s marketplace, a colleague’s, your company’s. The official and community names are accepted only for marketplaces whose source is under github.com/anthropics/, so a third-party catalogue cannot pass itself off as Anthropic’s. That tells you who publishes the catalogue, not what each plugin in it does.

Installing from the official marketplace

/plugin                                          # browse the Discover tab
/plugin install commit-commands@claude-plugins-official

Inside a session, /plugin install does not install straight away. It opens the plugin’s details, which list what it will install (commands, agents, skills, hooks, MCP and language servers) and, for official plugins, a context cost estimate. Then you pick a scope:

• User: for you, in every project on this machine. Recorded in ~/.claude/settings.json.
• Project: for everyone in this repository, recorded in the committed .claude/settings.json. Each colleague still installs it once on their own machine.
• Local: for you, in this repository only, in .claude/settings.local.json.

The install summary ends by saying whether the plugin is active now or needs /reload-plugins. To confirm it worked, type / and look for its skills under its name, such as /commit-commands:commit. The terminal, the desktop app’s local sessions and the VS Code extension read the same settings files, so a user-scope install in one appears in the others. Cloud sessions, including Claude Code on the web, do not load the plugins installed on your machine.

Installing from GitHub, another git host or a folder

There is no separate “install from a URL” for a plugin in a marketplace. You add the marketplace, once, then install from it by name. According to the install guide↗ (opens in a new tab), /plugin marketplace add accepts:

• A GitHub repository as owner/repo, with #ref to pin a branch or tag: your-org/plugins#v1.2.0.
• Any git host by full clone URL, such as https://gitlab.example.com/team/plugins.git. Type the https://; a bare host is read as GitHub shorthand and rejected.
• A local directory holding .claude-plugin/marketplace.json, or the file itself. Start relative paths with ./.
• A hosted marketplace.json by its https:// URL.

/plugin marketplace add your-org/claude-plugins
/plugin install deploy-helper@your-org-plugins

# recent versions can do both in one step
/plugin install deploy-helper --marketplace your-org/claude-plugins

The name after @ is the marketplace’s own name from its marketplace.json, which Claude Code prints when the add succeeds; it is not always the repository name. Private repositories work with the git credentials already on your machine, such as a gh auth login, and never prompt, so a host you have not signed in to simply fails.

A plugin that is only a folder, or a zip, with no marketplace around it, is loaded for one session rather than installed: claude --plugin-dir ./some-plugin, or claude --plugin-url with the address of a zip. That is the author’s testing route, and a sensible way to try something before you commit to it.

Listing, disabling, updating and removing

The Installed tab of /plugin lists every plugin with its scope. Space toggles one on or off; Enter opens it, with Update now and Uninstall. Plugins you have not used recently are grouped under their own heading, which is the list to prune. The same actions work from your shell, which is what setup scripts use:

claude plugin list
claude plugin disable formatter@your-org
claude plugin enable formatter@your-org
claude plugin update formatter@your-org
claude plugin uninstall formatter@your-org --scope project
claude plugin details formatter        # what it adds to every session

• Auto-update is on by default for the official marketplace and off for community and third-party ones. Change it per marketplace on the Marketplaces tab. An update reaches your next session, or the current one after /reload-plugins.
• Removing a marketplace uninstalls every plugin you installed from it, and Claude Code names them before it asks you to confirm.
• Uninstalling a plugin the repository enables asks whether to disable it for you only or remove it for everyone.

Before you trust one: a checklist

Anthropic’s plugin security page↗ (opens in a new tab) opens with the sentence that matters: a plugin you install can execute arbitrary code on your machine with your user privileges. Claude Code’s permission rules and sandbox govern the tool calls Claude makes, not the code a plugin runs by itself; hooks and MCP servers run outside the sandbox. So the review happens before you install, and it takes ten minutes:

1. Who publishes the marketplace? claude plugin marketplace list prints the source each one came from. An unfamiliar GitHub account is a reason to read more carefully, not a verdict.
2. What will it install? The details pane in /plugin lists its commands, agents, skills, hooks and servers. For a plugin fetched from elsewhere it may only say the components will be discovered at installation.
3. What do the hooks run? Open hooks/hooks.json in the plugin’s folder. A hook that formats files after an edit is ordinary; one that sends data somewhere should have a reason you can state.
4. What do the MCP servers start or reach? Read .mcp.json: a local command runs as a process on your machine, a URL is a service your session will talk to.
5. What is in bin/? Every file there is added to the path of Claude’s shell.
6. What do its skills grant themselves? Look for allowed-tools in each SKILL.md; it pre-approves tools whenever the skill runs.
7. Can you see the inventory before installing? Clone it and run claude --plugin-dir <folder> plugin details <name>, which lists every component without starting a session.
8. Will it change under you? With auto-update on, the files you reviewed can be replaced. For a third-party plugin, leave auto-update off, which is the default outside Anthropic’s marketplaces, and update by hand after reading what changed.
9. What does it cost? Enabled plugins put their skill and agent descriptions in context on every turn, even in sessions that never use them.

If you stop trusting one, claude plugin uninstall it at the scope you installed it, and remove the marketplace too if you no longer trust its owner. The plugin’s cached files stay under ~/.claude/plugins/cache/ for about two weeks unless you delete that folder yourself.

Plugins for a team

For one repository, commit the marketplace and the plugins in .claude/settings.json under extraKnownMarketplaces and enabledPlugins. Colleagues get the marketplace once they accept the workspace trust dialog for the folder. For a whole organisation, the same keys go in managed settings, which users cannot override, alongside the controls described in managing plugins for your organisation↗ (opens in a new tab):

• strictKnownMarketplaces: an allowlist of marketplace sources. Anything else cannot be added, and plugins already installed from elsewhere stop loading.
• blockedMarketplaces: a blocklist, checked before the allowlist.
• enabledPlugins set to true force-enables a plugin; false blocks it at every scope.
• disableSideloadFlags: rejects --plugin-dir and --plugin-url, which the allowlist does not cover.
• pluginTrustMessage: your own text appended to the warning shown before an install.

The wider rollout, from managed settings to onboarding, is in rolling out Claude Code to a team.

MCP servers are governed separately from plugins, even when a plugin brings them; which servers to approve and how to restrict them in Claude Code is in MCP governance.

You do not need a plugin to use a board

Some plugins exist mainly to bundle one MCP server. If what you want is a task board, the server is enough: fenbs connects with one claude mcp add command and a browser sign-in, with the scopes you tick, and nothing runs on your machine. What a plugin changes is how Claude works; what the board records is what was done, by whom. Every change an assistant makes through the connection is checked against its role and scopes and appears in the board’s history under its name. The everyday rhythm is in a task-tracking workflow for Claude Code.