Add Anthropic’s marketplaces and Claude Code can reach more than 6,000 plugin listings. Nothing in that catalog tells you which ones are worth the context they take. Claude Code plugins bundle skills, subagents, hooks, MCP servers and LSP servers into one unit, so a single install can add almost nothing or put 1,700 tokens into every session.
This guide covers the plugin marketplace commands, how to install Claude Code plugins at user, project and local scope, enable, disable, update, prune and reload, and the measured cost of nine official plugins from claude plugin details. Everything was built and run on Claude Code 2.1.310 on an Ubuntu 26.04 VM in October 2026, so every output block below is real. On that release the official marketplace auto-updates by default while community and third-party marketplaces don’t, claude plugin details needs 2.1.139 or newer, and claude plugin prune needs 2.1.121 or newer.
Tell plugins and skills apart
A plugin is a directory with a manifest that ships several Claude Code extensions together, and a skill is one of the things it can ship. You can drop a standalone skill into ~/.claude/skills/, write hooks in your own settings file, or register an MCP server by hand, and all of that works without any plugin. What the plugin adds is packaging: one install command, one version, one switch to turn the whole set off, and updates pulled from a marketplace.
That packaging is also why the “claude code plugins vs skills” question has a practical answer. If you wrote the skill yourself and only use it on one machine, keep it as a plain skill. If you want a team to get the same skills, subagents and hooks with one command, or you want someone else’s updates, use a plugin. A plugin can hold any mix of these components:
- Skills and slash commands, called as
/plugin-name:skill - Subagents Claude can hand work to
- Hooks that run on lifecycle events
- MCP servers that give Claude new tools
- LSP servers for code intelligence in a language
Each component type costs context differently, which is the part most plugin lists skip. Skill and agent descriptions sit in every session; hooks, MCP schemas and LSP servers don’t show up in the same count at all. The cost section further down puts real numbers on that.
Add the Anthropic plugin marketplaces
Anthropic runs three general-purpose GitHub marketplaces for Claude Code, and the roundup posts that rank for this topic tend to blur them. They differ in who writes the plugins and whether they update on their own, so it’s worth knowing which one a plugin came from before you install it:
| Marketplace name | GitHub repo | What’s in it | Entries (Oct 2026) | Auto-update default |
|---|---|---|---|---|
claude-plugins-official | anthropics/claude-plugins-official | Anthropic-built plugins plus vetted vendor plugins (GitHub, Context7, Playwright, Terraform) | 315 | On |
claude-community | anthropics/claude-plugins-community | Third-party submissions | 2,283 | Off |
claude-code-plugins | anthropics/claude-code | Demo plugins from the Claude Code repo, most also in the official marketplace | 12 | On |
Claude Code adds claude-plugins-official for you the first time you start an interactive session. On a box where you’ve only used the shell commands, as on this lab VM, the only marketplace listed is a built-in directory:
claude plugin marketplace list
That entry is a reserved, built-in catalog. It listed 3,598 plugins here, but none of the three GitHub marketplaces had been added yet:
Configured marketplaces:
❯ anthropic-plugin-directory
Source: Built in (Anthropic Directory)
Add the official marketplace with claude plugin marketplace add, which takes a GitHub owner/repo, a git URL, a URL to a marketplace.json or a local path. The same command adds the community and demo marketplaces if you want them:
claude plugin marketplace add anthropics/claude-plugins-official
claude plugin marketplace add anthropics/claude-plugins-community
claude plugin marketplace add anthropics/claude-code
Each add clones the repo over HTTPS when no GitHub SSH key is set up, validates the manifest and prints the marketplace name you’ll use in install commands. The repo name and the marketplace name are not always the same. anthropics/claude-code becomes claude-code-plugins:
Adding marketplace…SSH not configured, cloning via HTTPS: https://github.com/anthropics/claude-plugins-official.git
Refreshing marketplace cache (timeout: 120s)…
Cloning repository (timeout: 120s): https://github.com/anthropics/claude-plugins-official.git
Clone complete, validating marketplace…
Cleaning up old marketplace cache…
✔ Successfully added marketplace: claude-plugins-official (declared in user settings)
“Declared in user settings” means the command wrote an extraKnownMarketplaces block into ~/.claude/settings.json. Pass --scope project to put that declaration in the repo’s .claude/settings.json instead, which is how a team gets everyone pointed at the same marketplace. After the three adds, the user settings file held this:
{
"extraKnownMarketplaces": {
"claude-plugins-official": {
"source": {
"source": "github",
"repo": "anthropics/claude-plugins-official"
}
},
"claude-community": {
"source": {
"source": "github",
"repo": "anthropics/claude-plugins-community"
}
},
"claude-code-plugins": {
"source": {
"source": "github",
"repo": "anthropics/claude-code"
}
}
}
}
The entry counts in the table came from claude plugin list --available --json, which returns every plugin from every configured marketplace along with an installCount field. With all four sources configured it returned 6,208 entries. You do not need the community marketplace to follow the rest of this guide, and skipping it keeps the catalog down to plugins Anthropic has reviewed.
Install Claude Code plugins from the shell
Install a plugin with claude plugin install name@marketplace. The bare name works too, but the full form matters as soon as two marketplaces carry the same plugin, and five of the nine plugins installed below also sit in the demo marketplace. In fact 10 of the demo marketplace’s 12 plugins have a copy in the official one. This loop installs the nine plugins measured later in the guide:
for p in commit-commands code-review feature-dev security-guidance hookify plugin-dev pyright-lsp context7 github; do
claude plugin install "$p@claude-plugins-official"
done
Every install landed at user scope, because that’s the default when you don’t pass --scope. User scope writes only to ~/.claude/settings.json, so it doesn’t matter which directory you run the loop from. Each install took about a second, since the marketplace clone was already on disk:
Installing plugin "commit-commands@claude-plugins-official"...✔ Successfully installed plugin: commit-commands@claude-plugins-official (scope: user)
Installing plugin "code-review@claude-plugins-official"...✔ Successfully installed plugin: code-review@claude-plugins-official (scope: user)
Installing plugin "feature-dev@claude-plugins-official"...✔ Successfully installed plugin: feature-dev@claude-plugins-official (scope: user)
Check what’s installed and where with claude plugin list. Add --json when a script needs it, because the JSON also carries each plugin’s install path and any MCP server URLs it registers:
claude plugin list
The Version column tells you how each plugin is versioned. Plugins without a version in their manifest show the marketplace commit (58267944f921), while security-guidance and the LSP plugins carry a semantic version:
Installed plugins:
❯ code-review@claude-plugins-official
Version: 58267944f921
Scope: user
Status: ✔ enabled
❯ pyright-lsp@claude-plugins-official
Version: 1.0.0
Scope: user
Status: ✔ enabled
❯ security-guidance@claude-plugins-official
Version: 2.0.16
Scope: user
Status: ✔ enabled
Inside a session, /plugin opens the same catalog as a panel with Discover, Installed, Marketplaces and Errors tabs. /plugin install name@claude-plugins-official opens a details pane where you pick the scope, and nothing installs until you do. The panel wasn’t captured for this guide because the lab VM had no Claude login, so every output here comes from the non-interactive claude plugin commands, which need no login at all. If you’re starting from zero, the Claude Code install guide for Ubuntu 26.04 gets the CLI in place first.

The terminal capture above (claude plugin marketplace list and claude plugin list) was taken at the end of the lab run, after the demo marketplace had been removed and knowledge-work-plugins added, both covered further down. That’s why it shows four marketplaces where the first output block showed only the built-in directory.
Pick a scope: user, project or local
Scope decides which settings file records the plugin as enabled, and therefore who else gets it. All three write the same enabledPlugins key, and when the files disagree, local wins over project and project wins over user:
| Scope | Flag | File written | Who gets the plugin |
|---|---|---|---|
| User (default) | none, or --scope user | ~/.claude/settings.json | You, in every project |
| Project | --scope project | .claude/settings.json in the repo | Everyone who clones the repo and installs it |
| Local | --scope local | .claude/settings.local.json in the repo | You, in this repo only |
To see both repo scopes write their files, create a scratch git repo, install the TypeScript LSP plugin for the project and an output-style plugin for yourself only. The output-style plugin also exists in the official marketplace, but the demo copy is used here on purpose so the marketplace removal example later has something to uninstall:
mkdir -p ~/demo && cd ~/demo && git init -q
claude plugin install typescript-lsp@claude-plugins-official --scope project
claude plugin install explanatory-output-style@claude-code-plugins --scope local
Both report their scope on success, so a typo in the flag shows up right away instead of after a teammate wonders why a plugin appeared:
Installing plugin "typescript-lsp@claude-plugins-official"...✔ Successfully installed plugin: typescript-lsp@claude-plugins-official (scope: project)
Installing plugin "explanatory-output-style@claude-code-plugins"...✔ Successfully installed plugin: explanatory-output-style@claude-code-plugins (scope: local)
Now read the two files the installs created in the repo:
cat .claude/settings.json .claude/settings.local.json
Each file holds one entry, so a teammate who pulls the repo gets the TypeScript plugin enabled but never sees your output style. That split keeps personal preferences out of the shared config, which is the reason local scope exists at all. Here are both files:
{
"enabledPlugins": {
"typescript-lsp@claude-plugins-official": true
}
}
{
"enabledPlugins": {
"explanatory-output-style@claude-code-plugins": true
}
}
The local install did one more thing you might not expect. In the same second it wrote settings.local.json, Claude Code created ~/.config/git/ignore containing **/.claude/settings.local.json, so git status showed only .claude/settings.json as untracked. That’s the default location of your global git ignore file, so it now covers every repo on the machine. It’s a sensible default, but if you manage that file with a dotfiles tool, expect the extra line.
Run repo-scope commands from inside the repo. From the home directory, ~/.claude/settings.json is both your user file and that directory’s project file, and a claude plugin disable hookify --json run from ~ on the lab box reported "scope":"project" for a plugin installed at user scope.
Project scope only records the plugin as enabled. Each collaborator still runs the install once on their machine, from inside the repo, with the same flag: claude plugin install typescript-lsp@claude-plugins-official --scope project. The repo’s extraKnownMarketplaces entry also has to be there if the plugin comes from anything other than a marketplace they already have.
Disable, enable and uninstall a plugin
Disabling a plugin keeps it on disk and flips its enabledPlugins value to false. That’s the right move when a plugin’s skills or hooks get in the way for a while, since you can turn it back on without reinstalling. You also do not need to remember where it was installed. disable and enable find the scope on their own, checking local, then project, then user.
Disable the TypeScript plugin from inside the demo repo, without naming a scope:
claude plugin disable typescript-lsp
cat .claude/settings.json
The project file now carries the plugin as false instead of removing it, which is what you want to commit when a project should ship with a plugin turned off:
✔ Successfully disabled plugin: typescript-lsp (scope: project)
{
"enabledPlugins": {
"typescript-lsp@claude-plugins-official": false
}
}
Turn it back on with claude plugin enable typescript-lsp. There’s also claude plugin disable --all for ruling plugins out while debugging, but treat it with care: it writes false for every enabled plugin into your settings, the change sticks across sessions, and there is no enable --all. Save claude plugin list --json > plugins-before.json first so you know what to enable again one by one.
Uninstall does not auto-detect scope the same way. It defaults to user scope, so a project-scope plugin needs the flag:
claude plugin uninstall typescript-lsp --scope project
cat .claude/settings.json
After this the plugin’s entry is gone from .claude/settings.json, leaving an empty enabledPlugins object behind:
✔ Successfully uninstalled plugin: typescript-lsp (scope: project)
{
"enabledPlugins": {}
}
Watch for duplicates when you’ve added the demo marketplace. Running claude plugin install code-review with the official copy already present printed “is already installed”, but claude plugin install code-review@claude-code-plugins happily installed a second code-review at user scope next to the first. Both show as enabled, which is at best clutter and at worst two copies of the same skill competing for the same job. Install shared plugins from claude-plugins-official only, and remove the demo marketplace when you’re done trying its examples.
Update, prune and reload plugins
Plugins from claude-plugins-official update on their own. After your first message in an interactive session, Claude Code waits a random delay of up to ten minutes, refreshes every marketplace with auto-update on and updates its plugins on disk. The running session keeps the old version until you reload. The demo marketplace, claude-code-plugins, counts as an official name and auto-updates too. Community and third-party marketplaces, plus knowledge-work-plugins, default to off, so you update those yourself. Setting DISABLE_AUTOUPDATER=1, DISABLE_UPDATES=1 or CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 turns the whole pass off unless FORCE_AUTOUPDATE_PLUGINS=1 is also set.
A manual refresh is three steps, in this order:
- Refresh the marketplace listings with
claude plugin marketplace update. - Update each plugin with
claude plugin update name. - Run
/reload-pluginsin the session, or start a new one. If the reload would change MCP tools or the LSP tool, as it does forcontext7,githuband the LSP plugins, it applies nothing until you run/reload-plugins --force.
Start with the catalogs. The marketplace refresh never touches installed plugins:
claude plugin marketplace update
Every configured marketplace refreshed in one call:
Updating marketplaces...✔ Successfully updated 4 marketplaces
There is no update-all command for plugins, so each plugin gets its own update call:
claude plugin update commit-commands
Here the plugin was already current, because it had been installed minutes earlier from the same commit:
Checking for updates for plugin "commit-commands"…
✔ commit-commands is already at the latest version (58267944f921).
claude plugin prune removes plugins that were installed only as dependencies of something you’ve since uninstalled. It never removes a plugin you installed yourself, and --dry-run shows the list first. None of the plugins installed in this lab pulled in a dependency, so on this box there was nothing to remove:
claude plugin prune --dry-run
The command answers with a single line and exits 0. That makes it safe to leave in a cleanup script, because an empty prune is not treated as an error:
Nothing to prune (no auto-installed plugins at user scope).
Prune matters more once you use plugins from your own or a vendor’s marketplace that do declare dependencies. claude plugin uninstall name --prune does the same cleanup as part of the uninstall.
/reload-plugins loads plugin changes into a running session without a restart, and it also works in headless mode. Running it through claude -p at the end of the lab run printed a count of everything that loaded. At that point the TypeScript plugin was still enabled in the demo repo and productivity from the knowledge-work section was installed, so your totals will differ:
claude -p "/reload-plugins"
The summary is a quick sanity check after any install or update. When something fails to load, the line also reports how many errors happened during load, and the agents total counts all agents, not only plugin ones:
Reloaded: 10 plugins · 21 skills · 12 agents · 11 hooks · 2 plugin LSP servers
Closing the /plugin panel runs the same reload for you, so you will mostly type it after changing plugins from another terminal.
Measure what each plugin costs
claude plugin details answers the question every plugin roundup dodges: how many tokens does this add to my sessions? Run it in the shell against an installed plugin. Anthropic’s plugin cost documentation explains the two figures. Always-on is the name and description of every skill, agent and command, and it loads into every session whether you use the plugin or not. On-invoke is the body that loads each time one of them runs, so it only matters for the skills you actually call.
plugin-dev is the heaviest of the nine measured here, which makes it the best example to read:
claude plugin details plugin-dev
Eleven components at 30 to 300 tokens each add up to about 1,700 tokens on every session start, before you’ve asked for anything plugin-related:
plugin-dev
Description: Comprehensive toolkit for developing Claude Code plugins. Includes 7 expert skills covering hooks, MCP integration, commands, agents, and best practices. AI-assisted plugin creation and validation.
Source: plugin-dev@claude-plugins-official
Component inventory
Skills (8) agent-development, command-development, create-plugin, hook-development, mcp-integration, plugin-settings, plugin-structure, skill-development
Agents (3) agent-creator, plugin-validator, skill-reviewer
Hooks (0)
MCP servers (0)
LSP servers (0)
Projected token cost
Always-on: ~1,704 tok added to every session
Per-component (rounded)
component always-on on-invoke
agent-development ~100 ~2.7k
plugin-settings ~110 ~2.9k
mcp-integration ~120 ~3k
command-development ~130 ~4.6k
skill-development ~80 ~5.6k
hook-development ~140 ~3.9k
plugin-structure ~120 ~3.2k
agent-creator ~300 ~1.5k
plugin-validator ~300 ~1.3k
skill-reviewer ~290 ~1.2k
create-plugin ~30 ~3.9k
On-invoke cost is paid each time a skill or agent fires.
Token counts are estimates and may differ from actual usage.
The same command against all nine plugins gives the table below. Install counts come from the installCount field in claude plugin list --available --json on the same day, and the largest on-invoke figure is the most expensive single skill or agent in the plugin:
| Plugin | Components | Always-on | Largest on-invoke | Installs |
|---|---|---|---|---|
| code-review | 1 skill | ~13 tok | ~1.8k (code-review) | 477,558 |
| commit-commands | 3 skills | ~71 tok | ~420 (clean_gone) | 178,476 |
| feature-dev | 1 skill, 3 agents | ~194 tok | ~1.2k (feature-dev) | 269,187 |
| hookify | 5 skills, 1 agent, 4 hooks | ~218 tok | ~2k (writing-rules) | 63,891 |
| plugin-dev | 8 skills, 3 agents | ~1,704 tok | ~5.6k (skill-development) | 71,382 |
| security-guidance | 4 hooks | ~0 tok | none counted | 268,918 |
| pyright-lsp | 1 LSP server | ~0 tok | none counted | 118,419 |
| context7 | 1 MCP server | ~0 tok | not counted | 441,485 |
| github | 1 MCP server | ~0 tok | not counted | 345,391 |
Read the zeros carefully, because three of them mean “not measured” rather than “free”: context7, github and security-guidance. context7 and github show 0 because details doesn’t count MCP tool schemas, which are only resolved when a session connects to the server. Check /context in a live session to see what their tools take. Hooks are labelled harness-only with no model context cost, which holds for most hooks but not all. security-guidance runs hooks on UserPromptSubmit and PostToolUse that can add reminders to the conversation, and its description promises an LLM review on Stop. explanatory-output-style also reports 0, yet its SessionStart hook prints 1,303 characters of additionalContext into each session. That is roughly 300 tokens at the usual four characters per token.
The LSP plugins really are close to free in context, but they are not complete on their own. The installed pyright-lsp directory holds only a LICENSE and a README, because its LSP settings live in the marketplace entry, so it does nothing until you install the pyright binary yourself with npm install -g pyright or pipx install pyright. Skip that step and the plugin sits in your list looking enabled while Claude gets no type information.
For comparison with plugin-dev, this is commit-commands, the lightest of the skill-based plugins after code-review, as the terminal shows it:

The figures are Claude Code’s own estimates, and the docs say actual usage can differ. They’re still the right tool for comparing plugins, and for spotting the one that quietly takes more context than the other eight combined. If session size is already a problem, the tested ways to reduce Claude Code token usage pair well with pruning heavy plugins.
Auditing a machine that already has a pile of plugins takes three commands, and it’s worth doing after any burst of installs:
- Run
claude plugin listto see every plugin and its scope. - Run
claude plugin details nameon each one and note the Always-on line. - Disable anything over a few hundred tokens that you haven’t called this week.
Choose the best Claude Code plugins to install first
Pick by the job you repeat most, not by install count. The official marketplace’s most installed plugin is frontend-design at 1,266,133 installs, which tells you about popularity and nothing about your workflow. Based on the measured costs above, this order gives the most value per token for someone working in git repos every day:
- Install
code-reviewfor pull request reviews: 13 tokens always-on, about 1.8k only when you run it. - Add
commit-commandsfor/commit-commands:commitandcommit-push-pr: 71 tokens always-on. - Add the LSP plugin for your main language (
pyright-lsp,typescript-lsp) and install its binary. - Add
security-guidanceif Claude writes code you ship; it works through hooks, not context. - Add
feature-devwhen you build multi-file features and want its explorer, architect and reviewer agents. - Install
plugin-devonly while you write plugins, then disable it.
Vendor plugins in the official marketplace are a different trade. github and context7 are thin wrappers that register an MCP server, and Context7’s points at https://mcp.context7.com/mcp with no API key required. Installing them through a plugin mostly saves you the manual claude mcp add step and gets you updates. Install one when you’d have added that MCP server anyway. The github plugin’s .mcp.json sends Authorization: Bearer ${GITHUB_PERSONAL_ACCESS_TOKEN} to https://api.githubcopilot.com/mcp/, so export a GitHub personal access token in that variable before starting Claude Code or the server can’t authenticate. hookify earns its 218 tokens only if you write your own guardrail rules often; otherwise plain hooks in settings do the same job for zero context. For memory across sessions, claude-mem is a separate install with its own trade-offs.
On “claude code plugins github” searches: the official catalog lives in the anthropics/claude-plugins-official repo, where Anthropic-built plugins sit under plugins/ and third-party ones under external_plugins/ or point at the vendor’s own repo. Reading a plugin’s directory there before installing it shows you every hook script and MCP URL it’ll run.
Add knowledge-work-plugins for Claude Cowork roles
knowledge-work-plugins is another Anthropic marketplace, and it isn’t aimed at developers. Its README says the plugins are built for Claude Cowork and also work in Claude Code, and they cover roles such as sales, finance, legal, marketing, customer support, product management and productivity. Add it from the shell like any other marketplace:
claude plugin marketplace add anthropics/knowledge-work-plugins
claude plugin install productivity@knowledge-work-plugins
claude plugin details productivity
The details output shows why these are a different kind of plugin. productivity carries four skills and nine MCP connectors for the apps a non-developer lives in:
Component inventory
Skills (4) memory-management, start, task-management, update
Agents (0)
Hooks (0)
MCP servers (9) slack, notion, asana, linear, atlassian, monday, clickup, google calendar, gmail (tool schemas resolved at runtime; not counted)
LSP servers (0)
Projected token cost
Always-on: ~270 tok added to every session
This marketplace does not auto-update by default, so run claude plugin marketplace update knowledge-work-plugins now and then if you keep any of its plugins. Cowork users install the same plugins from the Cowork app instead of the CLI.
Fix common plugin errors
Every error below was hit on the lab VM. All of them exit with status 1, which matters if you script plugin installs in a dotfiles or CI setup.
Failed to add marketplace: Fetching the marketplace from GitHub failed on both attempts
This came from a repo name that doesn’t exist (anthropics/no-such-marketplace). Claude Code tries HTTPS first, gets fatal: unable to get password from user because GitHub asks for credentials on a missing or private repo, then falls back to SSH and fails on the unknown host key:
✘ Failed to add marketplace: Fetching the marketplace from GitHub failed on both attempts. HTTPS (https://github.com/anthropics/no-such-marketplace.git): Failed to clone marketplace repository: Cloning into '/home/joshua/.claude/plugins/marketplaces/anthropics-no-such-marketplace..clone'...
fatal: unable to get password from user
SSH ([email protected]:anthropics/no-such-marketplace.git): Failed to clone marketplace repository: SSH host key is not in your known_hosts file.
The SSH part is a red herring. Check the owner/repo spelling first, and for a private repo make sure your git credential helper or gh auth can clone it before Claude Code tries.
Plugin “not-a-plugin” not found in marketplace “claude-plugins-official”
The name doesn’t match any entry in that marketplace’s current listing, either from a typo or because the plugin lives in a different marketplace. Search the catalog instead of guessing. --available only works together with --json:
claude plugin list --available --json | grep '"pluginId"' | grep -i review
Each hit carries the exact name@marketplace string to paste into the install command. The first five matches on the lab box:
"pluginId": "code-review@claude-plugins-official",
"pluginId": "pr-review-toolkit@claude-plugins-official",
"pluginId": "access-review@claude-community",
"pluginId": "adversarial-review@claude-community",
"pluginId": "byom-review@claude-community",
If you know the plugin was added recently, run claude plugin marketplace update first, since a stale local clone won’t list it.
Plugin is not installed in user scope. Use –scope to specify the correct scope.
You ran claude plugin uninstall name on a plugin installed at project or local scope. Uninstall only looks at user scope unless told otherwise, even though disable found the same plugin without help. Run claude plugin list, read the Scope line and pass it: claude plugin uninstall typescript-lsp --scope project.
Plugin “plugin-dev” is already disabled
Running disable on a disabled plugin, or enable on an enabled one, prints this and exits 1 even though the end state is what you asked for. In a setup script, pass --json and check the result instead of the exit code. A repeat disable returns "failureCode":"already_in_goal_state" and "alreadyInGoalState":true, which you can treat as success.
Keep the plugin commands handy
Every command from this guide in one place. claude plugins works as an alias for claude plugin, and the full command list sits in the Claude Code cheat sheet alongside the rest of the CLI:
| Task | Command |
|---|---|
| Add a marketplace | claude plugin marketplace add owner/repo |
| List marketplaces | claude plugin marketplace list |
| Refresh catalogs | claude plugin marketplace update |
| Remove a marketplace and its plugins | claude plugin marketplace remove name |
| Install at user scope | claude plugin install name@marketplace |
| Install for the repo | claude plugin install name@marketplace --scope project |
| Install for you in this repo | claude plugin install name@marketplace --scope local |
| List installed | claude plugin list |
| Show cost and components | claude plugin details name |
| Disable or enable | claude plugin disable name / claude plugin enable name |
| Update one plugin | claude plugin update name |
| Uninstall (user scope) | claude plugin uninstall name |
| Uninstall from the repo | claude plugin uninstall name --scope project |
| Remove orphaned dependencies | claude plugin prune --dry-run, then claude plugin prune -y |
| Load changes into a session | /reload-plugins |
Removing a marketplace is the one command here with a wide blast radius. claude plugin marketplace remove claude-code-plugins also uninstalled explanatory-output-style. Its output says the removal deletes saved options, secrets and data where it can, so list what came from a marketplace before you drop it.