Plugins & marketplaces

What a plugin is

A plugin is the packaging unit that bundles a CLI’s extension primitives — skills, hooks, subagents, MCP servers, commands — into one installable thing. Instead of dropping six files in six different directories, you install one plugin and the whole set lands together, namespaced so it doesn’t collide with anything else.

Across the tools in scope:

Claude Code has plugins and marketplaces (hosted plugin collections you browse from inside the CLI).
Copilot has the densest surface: Extensions (Chat-centric, GitHub Marketplace) and plugins (bundle skills + agents + hooks + MCP + LSP, distributed via marketplaces — preview in 2026).
opencode has plugins as JS/TS modules; no marketplace concept of its own, but an awesome-opencode community index.
Cursor inherits the VS Code extension model (OpenVSX-backed) plus an MCP Marketplace, but has no first-class “bundle of rules + skills + agents + hooks” plugin format yet.
Codex has no first-class plugin format — you compose its primitives (skills, MCP, SDK) directly. That’s a deliberate design choice as much as a gap.

Why you’d want one

You’ve spent the last month building up the way you use Claude Code: a deploy-checklist skill, a security-reviewer subagent, a hook that runs the linter after every edit, an MCP server pointed at your Linear, three slash commands for the team’s pre-merge workflow. It all lives in .claude/ inside one repo. It works beautifully.

Then you start a second repo. You want the same setup. So you copy .claude/ across. Then a new teammate joins — “how do you get this stuff?” — and the answer is “clone my dotfiles, copy these directories, edit your settings.json, install these MCP servers, oh, you also need…” The setup that worked beautifully in one repo doesn’t survive contact with anyone else’s filesystem.

That’s the gap plugins close. The same skill + subagent + hook + MCP bundle becomes one installable thing, namespaced so two plugins don’t fight, distributable through a marketplace so your teammate runs /plugin install team-stack@our-marketplace and gets the whole setup. Sharing your way of working with the agent shifts from “follow these eleven steps” to “install this.”

Real-world examples of what teams actually package as plugins:

Team conventions bundle — your repo’s style guide as a skill, a pre-commit linting hook, a code-review subagent, an MCP server for your issue tracker. One install, whole-team consistency.
Domain plugins — a “payments” plugin with PCI-aware skills, an audit-log hook, and a subagent that knows the payment processor’s API.
Personal toolkit — your own /tldr, /skeptic, /pre-ship commands plus your favourite review subagent. Install on every machine you use, kept in sync via the marketplace.
Open-source plugins — community-maintained bundles for a specific stack (Rust + Tokio, Next.js + Drizzle, Django + Celery). Skill + agent + permissions tuned for that stack.
Org-wide standards — managed-scope plugin installed on every dev’s machine: enforce the security hook, the audit MCP server, the approved-subagent list. The team has no choice about installing it.
Workshop / tutorial materials — pin a known-good toolkit for a workshop so every attendee starts from the same baseline.

The test: if you’ve ever found yourself emailing someone a zip of your .claude/ folder, or telling them “first, copy these files…”, you wanted a plugin.

Why this and not…

You want to…	Reach for	Not
Bundle multiple primitives (skills + hooks + agents + MCP) as one unit	Plugin	Loose files
Share that bundle with teammates / a community	Plugin (via a marketplace)	A README with copy-paste instructions
Distribute just a single skill	A standalone skill folder (especially `SKILL.md` is cross-tool portable)	Wrapping it in a plugin
Add one MCP server	MCP config directly	Plugin-wrapping it
Enforce a configuration across the org	Managed-scope plugin (Claude Code) / managed config	Plugin marketplace alone
Add live event-handling code (opencode)	opencode plugin (JS/TS)	Static skill

A plugin pays its weight when there are multiple extension pieces that belong together. A single skill or single hook doesn’t need a plugin wrapper — keep it as a loose file until you find yourself shipping it alongside something else.

How it works in each tool

A plugin is a directory bundling some combination of:

Skills (skills/<name>/SKILL.md)
Subagents (agents/<name>.md)
Hooks
MCP servers
Commands

Each plugin’s skills/commands are namespaced when installed — they appear as /my-plugin:cmd so multiple plugins coexist without colliding.

Marketplaces are hosted collections of plugins. You point Claude Code at a marketplace URL and browse/install from inside the CLI.

Marketplace commands:

/plugin marketplace add <owner/repo | git-url | local-path | marketplace.json-url>
/plugin marketplace list
/plugin marketplace update <marketplace-name>
/plugin marketplace remove <marketplace-name>

(/plugin market is a shortcut for /plugin marketplace; rm aliases remove.)

Plugin commands:

/plugin install <plugin>@<marketplace>
/plugin enable|disable <plugin>@<marketplace>
/plugin uninstall <plugin>@<marketplace>
/reload-plugins                            # hot-reload without restart
claude plugin install <plugin>@<marketplace> --scope project

Scopes: user (default), project (committed to .claude/settings.json), local (this repo, not shared), managed (admin-set).

On-disk layout: installed plugins are copied into a cache rooted at ~/.claude/plugins/cache/. Because plugins live in the cache (not their source repo), paths referencing files outside the plugin directory don’t work. Plugin skills are namespaced under the plugin (e.g. commit-commands exposes /commit-commands:commit). Project-scope marketplaces are registered in .claude/settings.json under extraKnownMarketplaces. The official Anthropic marketplace claude-plugins-official is auto-available.

A plugin is a JS/TS module that exports a function. The function receives a context (project, client, $, directory, worktree) and returns a map of hook handlers and/or tool definitions.

export default ({ project, client, $ }) => ({
  hooks: {
    'file.edited': async (event) => { /* ... */ },
  },
  tools: {
    myCustomTool: {
      schema: /* Zod schema */,
      execute: async (input) => { /* ... */ },
    },
  },
});

Plugins are live JS code, not static bundles — closer in spirit to a VS Code extension than to a Claude Code plugin.

Discovery / loading. Two paths:

Local files in .opencode/plugins/ (project) or ~/.config/opencode/plugins/ (global) — auto-loaded at startup.
npm packages listed under the top-level plugin array in opencode.json — installed automatically using Bun at startup (e.g. "plugin": ["opencode-helicone-session", "@my-org/custom-plugin"]). Packages and their dependencies are cached in ~/.cache/opencode/node_modules/.

Slash commands. The plugin docs describe hook subscriptions (e.g. file.edited, tool.execute.before, session.created) and custom tool registration, but do not document slash-command registration as a plugin capability. Slash commands live in .opencode/commands/ as standalone markdown files.

Ecosystem. No official registry. The community index is awesome-opencode; the docs ecosystem page also links community plugins.

Cursor’s plugin surface is broader than its CLI peers because it inherits the VS Code extension model:

Extensions — installed from Cursor’s OpenVSX-backed marketplace and from Anysphere-published mirrors of popular VS Code extensions. Microsoft’s official marketplace is not accessible. Coverage is meaningfully less than upstream VS Code; some extensions never ship to OpenVSX. Side-loading .vsix files works for the ones that don’t.
MCP Marketplace — in-app browser plus cursor.directory with one-click install. This is the closest analog to a “skills/agents marketplace” for context-engineering content.
Rules / Skills / Subagents / Commands — no official central registry for these yet; the community shares them on GitHub repos and in cursor.directory. Unverified whether an official rules/skills marketplace ships in 2026.
Cursor Marketplace (general) — referenced in MCP docs as the surface for official, vetted MCP plugins.

There is no formal “plugin” abstraction that bundles rules + skills + hooks + subagents together (a community feature request exists at forum.cursor.com/t/151250). For now, sharing a Cursor configuration means sharing the relevant .cursor/* files directly.

Copilot has the densest plugin/marketplace surface of any CLI in foundations scope. Two distinct primitives, both shipping in 2026:

Copilot Extensions — @-invocable in Chat:

Two flavors: Skillsets (lightweight, retrieval-focused) and Agents (full LLM-backed responders)
Distributed via GitHub Marketplace (github.com/marketplace?type=apps&copilot_app=true)
Invoked as @extension-name in VS Code Chat
Built with the Copilot Extensions SDK
Reference impls in the copilot-extensions org

Copilot plugins (distinct from Extensions; preview as of 2026):

Bundle agents + skills + hooks + MCP server configs + LSP configs into one installable unit
Format shared between VS Code agent plugins and Copilot CLI plugins
Distributed via plugin marketplaces — Copilot ships with two default marketplaces registered: github/copilot-plugins (official) and github/awesome-copilot (community, 48+ plugins)
Marketplaces can be hosted on github.com, any Git server, or a local filesystem
Enterprise admins can configure baseline plugins available to every user

MCP Registry (github.com/mcp) — curated, one-click MCP server install from inside the IDE. Separate from the plugin marketplace; MCP servers are a component plugins can ship, not a replacement for them.

awesome-copilot is the practical jump-off: real-world instructions, prompts, skills, agents, hooks, and plugins published by GitHub and the community.

Note the terminology overload: Extensions (Marketplace, @-invocable, Chat-centric) and plugins (marketplace-registered, bundle-of-everything) are different things with overlapping but distinct distribution mechanics.

Comparison

Aspect	Claude Code	Codex	opencode	Cursor	Copilot
First-class plugin format	Yes (static bundle)	No	Yes (live JS/TS)	No (bundle of rules + skills + agents)	Yes (preview, 2026)
Bundles skills + hooks + agents + MCP	Yes	—	Yes (via plugin code)	—	Yes (skills + agents + hooks + MCP + LSP)
Namespacing	`/plugin:cmd`	—	Slash commands not a documented plugin capability	—	Plugin-scoped
Distribution mechanism	Marketplaces	—	npm + community `awesome-opencode` index	OpenVSX extensions + MCP Marketplace (cursor.directory)	GitHub Marketplace (Extensions), plus plugin marketplaces (default: `github/copilot-plugins`, `github/awesome-copilot`)
Closest analogue (if no native plugins)	—	Skills + MCP + SDK	—	Share `.cursor/*` files directly	—
Separate `@`-invocable extension surface	—	—	—	—	Copilot Extensions (Skillsets / Agents) via GitHub Marketplace

Name collisions

A Claude Code plugin is a static bundle of files. An opencode plugin is live JS/TS code. They are not the same abstraction layer — one is content packaging, the other is event-driven code.
Codex’s lack of plugins isn’t an oversight — the design treats skills + MCP + SDK as a sufficient composition surface. Don’t recommend “wait for plugins”; recommend the existing primitives.
In Copilot, Extensions and plugins are two distinct primitives that both ship in 2026. Extensions are @-invocable Chat agents distributed via GitHub Marketplace; plugins are marketplace-registered bundles (skills + agents + hooks + MCP + LSP) for VS Code Chat and Copilot CLI. Don’t conflate them.
Cursor doesn’t yet have a “bundle of rules + skills + subagents + hooks” plugin abstraction. Its plugin-like surfaces are inherited from the VS Code extension model and the MCP Marketplace, not a Cursor-native packaging format.