Claude Code Plugins in 2026: Install, Configure and Remove Them Safely

A plugin can make a recurring development task easier to repeat. It can also add instructions, processes and connections you do not need. The useful question is which part of your workflow needs help: reviewing a pull request, navigating a TypeScript codebase, preparing a commit, or connecting to another service.

This guide follows that decision through installation, scope, configuration, updates and removal. Official documentation and public repository files were checked on 9 October 2026. The command examples were source-checked; they were not executed in a Claude Code session. No benchmark, reliability ranking or hands-on result is claimed. Our evidence policy explains that distinction.

What a Claude Code plugin actually adds

A plugin is a directory of extensions that Claude Code loads as a unit. It may include skills, subagents, hooks, MCP servers and other supported components. A manifest at .claude-plugin/plugin.json names the package and can declare its version and configuration. A plugin does not need every component to be useful. See Anthropic's plugin overview.

Think of a team review workflow. Instructions explain what to check; a subagent investigates a particular area; a hook reacts to an event; an MCP server provides tools for another system. A plugin can distribute those pieces together. That packaging is the reason to install it. It does not prove that the workflow suits your repository or that the generated findings are correct.

Plugins, skills and MCP servers solve different parts of a task

A skill can teach Claude how to review an API change. An MCP server can supply the issue or pull-request tools that the review needs. A plugin can package the workflow and connection. Installing a plugin that contains an MCP server still leaves the server's authentication and service permissions to resolve; the package is not a free pass into that service. The skills documentation and MCP guide explain the individual extension types.

For a single project checklist, a standalone skill is often enough. Our Claude Code skills guide covers that smaller starting point. This article focuses on managing an installed package, rather than rewriting the same skill-authoring tutorial.

Start with one job and one plugin

Write down the outcome before opening a catalog. “Help review a pull request before I merge it” is a useful task. “Install the best AI development stack” leaves you with no clear way to decide which extensions to keep.

For your first plugin, identify the expected input, the action it may take, and the output you will inspect. A review plugin might read a diff and post a comment. A commit plugin might stage files and create a commit. Those actions deserve different permission and review decisions, even if both appear under a development category.

Choose a small task in a repository you can safely change. Keep the work on a branch, understand any pending changes, and decide whether the plugin may write files or contact an external service. This is a suggested evaluation method, not a report of an evaluation performed for this guide.

Find the actual official marketplace

Claude Code normally registers claude-plugins-official when you first start an interactive terminal session, unless policy or configuration prevents it. Open /plugin and use Discover to browse the available entries. Anthropic's marketplace guide distinguishes its official, community and demo catalogs.

The official marketplace contains Anthropic-maintained plugins and plugins from partners and other authors. Check the author and repository for the individual entry. The catalog's name establishes its origin; it does not mean that Anthropic wrote every plugin or that an extension has been proven safe for your task.

If the official catalog is missing, register its actual repository inside a Claude Code session:

/plugin marketplace add anthropics/claude-plugins-official

Older tutorials may add anthropics/claude-code instead. That is the demo marketplace, named claude-code-plugins. Prefer the official entry when the same plugin appears in both; two copies make loading and updates harder to reason about.

Adding a marketplace does not install its entire catalog. You still choose a plugin and an installation scope. Check the official catalog snapshot if you want to confirm the names used in this guide.

Install a plugin and read the result

Start with a working, authenticated local Claude Code installation. The setup guide covers macOS, Linux, native Windows and WSL; check that claude --version works in the terminal you will use. On native Windows, Git for Windows provides Git Bash but is not required for Claude Code's PowerShell tool. The examples below target an interactive local terminal session. A cloud session does not inherit the plugins you installed on your own computer.

Use a current supported release and check your installed command help when a subcommand differs. Current documentation does not give one universal minimum version covering every plugin feature described here. The Git commit example needs Git and a repository; the GitHub review workflow needs gh and appropriate repository access. Those are prerequisites for those workflows, rather than requirements for every plugin.

In an interactive terminal session, run /plugin, select a plugin in Discover, inspect its details, and choose a scope. The installation guide documents the same workflow across supported local surfaces.

For a concrete example, this command opens the official commit-commands entry inside Claude Code:

/plugin install commit-commands@claude-plugins-official

If you prefer installing from your normal terminal, use the shell form. This example installs only for you in the current repository:

claude plugin install commit-commands@claude-plugins-official --scope local

The slash-command form belongs at Claude Code's prompt. The claude plugin form belongs in your shell. Pasting /plugin into PowerShell or zsh will not open Claude Code's plugin manager.

Read the result before trying a command. The install summary can report that the plugin is already active, that a bundled MCP server needs configuration, that a reload is needed, or that loading failed. Do not assume that every successful download requires a restart, or that every installed plugin is ready to use.

When a reload is requested in an open session, use:

/reload-plugins

Follow any cache-cost warning rather than automatically forcing it. For a shell installation, start a new session or reload an existing one. Then type / to discover the plugin's actual namespaced skills. In this example, look for /commit-commands:commit before running it.

Choose the smallest appropriate installation scope

Scope answers who should have the plugin enabled, not whether the plugin is safe. Local scope is a sensible first choice for a repository-specific evaluation. User scope fits a tool you deliberately want across projects. Project scope fits a team-approved setup you intend to share.

When settings conflict, local settings take precedence over project settings, then user settings. Managed organization policy can override your choices. Anthropic's loading reference explains the settings, disk and session layers.

Committing project settings does not bundle downloaded plugin files into Git. Each collaborator still needs the applicable installation on their own machine. Put the required plugin name, marketplace, setup steps and expected permissions in the team's development instructions, so a fresh checkout is understandable.

For example, a team might agree to use commit-commands in a repository but still require human review before staging changes. That agreement is an operational rule, not something the plugin's scope enforces. Keep personal credentials and private configuration out of the committed settings file.

Useful official examples, chosen by task

These examples were selected to illustrate different jobs, not ranked by speed, adoption or benchmark results. Their current files were inspected at official repository commit 315c4e48967d9541c29c3c656441dded353ca7aa. Start with the one that matches your task; installing every example adds unnecessary moving parts.

commit-commands: prepare a commit deliberately

The commit command's source supplies Git status, diff, branch and recent history, then directs Claude to stage and create a commit. That is a writing action on repository history. Review the diff and files first, especially when several unrelated changes are present.

Use the commit workflow when you have already checked a coherent change. Avoid treating its generated message as proof that tests passed. The plugin README also describes a broader commit/push/PR workflow; that is a separate external action and should not be run merely because you wanted a local commit.

code-review: a pull-request review with external effects

The current code-review command checks pull-request eligibility, examines changes and repository guidance, uses multiple agents to investigate, and can post a GitHub comment through gh. Read the command before invoking it against a live pull request.

The source explicitly leaves builds and type checking to separate CI checks. A review comment is therefore neither a successful build nor a security audit. Use it as another review input, inspect the cited lines, and keep your normal tests and human review.

feature-dev: explore a substantial change before editing

The feature-dev README describes a staged workflow covering discovery, code exploration, clarification, architecture, implementation, review and summary. It is a candidate for changes with genuine design choices, such as adding an integration to an established application.

Give it a bounded outcome: “Add CSV export to the existing report page, preserve its access checks, and use the current test setup.” That is an original example prompt, not an executed result. For a one-line copy correction, the same planning workflow may create more overhead than it removes.

typescript-lsp: connect code intelligence, then verify the binary

The official code intelligence guide explains how language-server plugins add diagnostics and symbol navigation in terminal sessions. typescript-lsp configures a TypeScript/JavaScript language server, but the plugin does not include the executable. Its README identifies typescript-language-server and typescript as prerequisites.

Install prerequisites through your team's approved package-management process. Check that the executable is available to the terminal launching Claude Code, then inspect the plugin's status. Language-server diagnostics help during editing; keep the project's build and tests. The documented plugin language servers are not started in Claude Code cloud sessions, so a local installation is not evidence of equivalent cloud functionality.

Inspect permissions and executable components before enabling

Read the individual plugin's source, not only its marketing description. Anthropic's plugin security documentation states that plugins can execute code with your user privileges. Its hooks, monitors and server processes run outside the Bash sandbox. Tool-call permission rules still apply to Claude's calls, but they do not turn independently running plugin code into a sandboxed process.

Check hook commands, MCP server commands or URLs, and any executables in bin/. A details panel can establish that a hook exists without showing its entire behavior. Ask what each component reads, writes or sends, and which account owns any remote service it reaches. The component reference explains additional features such as background monitors and JavaScript mods; do not assume an unfamiliar component is merely text.

For a team installation, make the review concrete: record the repository revision you inspected, expected service domains, required local tools and actions that need review. Compare those expectations after an update. A popular listing, a familiar name or an “official” catalog entry does not replace that work.

Use permission settings for the actions Claude can take. Avoid granting broad write or network privileges simply to suppress a prompt. If the plugin needs a production credential before you understand its behavior, pause and choose a smaller evaluation environment. Bash sandboxing adds boundaries where supported, but it is not a general containment guarantee for every plugin component.

Configure the connection without committing secrets

An installed package may still need a service endpoint, account connection or other option. Open the plugin on the Installed tab of /plugin and use its configuration controls. If a bundled MCP server needs setup, complete that server's options and authentication flow rather than repeatedly reinstalling the package.

Plugin authors can declare userConfig fields. The manifest reference documents sensitive fields that mask input and use secure credential storage instead of settings.json. Confirm how the specific plugin declares and uses its secrets. A field's storage choice does not establish what its remote service receives or how long that service retains data.

Use the narrowest service permissions that complete the task. Keep real tokens out of chat, example prompts, screenshots, source files and committed configuration. When troubleshooting, replace account identifiers, headers and credentials with clear redactions before sharing a log. Never post the unredacted log just because a plugin manager produced it.

Updates: separate the catalog, installed files and active session

A marketplace refresh and a plugin update are different operations. Refreshing a catalog tells Claude Code what releases exist; changing the installed plugin replaces its files. A running session can still hold the version it loaded earlier. Keep those three states in mind when a reported update seems to have no effect.

Use this shell command to request the current marketplace version of the example plugin at the same local scope:

claude plugin update commit-commands@claude-plugins-official --scope local

Then follow the result's reload instruction or start a new session. The command reference documents update scope and installed-plugin management. Naming the scope makes the example's intent explicit and avoids depending on older default behavior.

Auto-update is controlled per marketplace; the official marketplace normally has it enabled. Inspect the Marketplaces tab instead of assuming a third-party catalog follows the same default. The loading reference describes when on-disk updates and session reloads occur. Some components, including monitors, need a session restart for a changed version.

A plugin can also depend on other plugins. Anthropic's dependency documentation explains those relationships and version constraints. Review the install or update summary for added dependencies. For important workflows, evaluate the changed package and dependencies before allowing them into repositories with valuable credentials or release access.

Troubleshoot the layer that actually failed

Start with the Installed and Errors tabs in /plugin. Record the specific message and scope. An absent command, a missing executable and failed service authentication are different failures, and reinstalling everything may obscure the first useful clue.

These checks follow the plugin troubleshooting guide and the loading model. If you need to see installed versions and scopes from your normal terminal, use:

claude plugin list

For a package's component inventory and projected context cost, use:

claude plugin details commit-commands

Treat a projected token figure as an estimate, not a measured saving. The cost and usage guide distinguishes component inventory, always-present descriptions and content loaded on invocation. We have not measured this example plugin's runtime usage.

If troubleshooting still fails, share the exact command, plugin ID, scope, version and sanitized error with the maintainer. Avoid manual edits to cached plugin files as a long-term fix: you may be changing a copy that the next update replaces. If a policy blocks the plugin, ask the organization's administrator to review it rather than trying to bypass the policy.

Disable or remove a plugin you no longer need

Disabling stops a plugin from being selected for future loading without uninstalling its package. Use the Installed tab if you want to try working without it. Apply pending changes or restart the session as the manager directs. A running background monitor does not necessarily stop just because you disabled its plugin mid-session.

To remove the local example installation, run:

claude plugin uninstall commit-commands@claude-plugins-official --scope local

Read the uninstall result. Other installed scopes can keep a plugin present. At the last scope, removal normally deletes saved options and persistent data, with documented exceptions such as data preservation; cached files can remain for later cleanup. Consult the command reference if retained files matter to your case.

Removing a marketplace is broader than removing one plugin: it uninstalls plugins from that catalog. Do not use it as a shortcut when you only want to stop one extension. Removing local files also cannot recall information already sent to an external service. Revoke unnecessary service access separately through that service's account controls.

When you can skip plugins

Stay with a standalone skill when you need one project procedure and have no distribution or integration requirement. Stay with an existing MCP connection when it already supplies the external tools you need. A plugin is useful when its packaging, maintained workflow or combined setup removes a real recurring problem.

Keep your enabled set small enough to explain. Names and descriptions of enabled skills and agents consume context even when you do not invoke them; the usage documentation shows how to inspect that footprint. More installed extensions do not establish better answers or fewer errors.

For your next session, choose one task, inspect one matching plugin, install it at the appropriate scope, and verify its actual result before expanding your setup. Keep it only if it helps the work you do. If your need is a repeatable instruction rather than a package, begin with the skills guide in our AI Coding & Agents pillar.