Your Claude Plugin Marketplace Needs More Than a Git Repo

Anthropic's official plugin directory has 55+ curated Claude Code plugins since launch. The community tracks another 72. By end of 2026, most large engineering orgs will have a private marketplace too — and most of them will ship the architecture wrong.

The mistake: treating the marketplace as a distribution channel when it's actually a governance layer.

What a Claude Code Plugin Actually Is

A plugin is a directory with a .claude-plugin/plugin.json manifest and some combination of skills (skills/<name>/SKILL.md), agents, hooks, and MCP servers. When a user runs /plugin install code-formatter@acme-tools, Claude Code clones the plugin to ~/.claude/plugins/cache/<marketplace>/<plugin>/<version>/ and loads it into the session.

Critical point: plugins run fully trusted code inside your developers' sessions. Skills execute shell commands. MCP servers install arbitrary binaries. Hooks intercept every tool call. There is no sandboxing in 2026. Trust is transitive — trust the Git host, trust the repo's access control, trust the authors.

That's what "setting up your own marketplace" is really about. Distribution is the easy part.

The Three-Layer Model

Most engineers see plugins and think "install mechanism." The actual hierarchy is three layers:

Skills do the work. The marketplace decides which skills exist. Managed settings decide which marketplaces your employees can reach at all.

Skip layer 3 and you've built a distribution channel, not an enterprise platform.

The Manifest That Matters

marketplace.json looks deceptively simple:

{
  "name": "acme-tools",
  "owner": {"name": "DevTools Team"},
  "plugins": [
    {
      "name": "sfdc-lint",
      "source": {
        "source": "github",
        "repo": "acme-corp/sfdc-lint-plugin",
        "ref": "v2.1.0",
        "sha": "a1b2c3d4e5f6..."
      },
      "description": "Blocks commits that violate Salesforce field access rules"
    }
  ]
}

The sha field is the thing nobody talks about. Pin to a commit hash, not a tag. Tags move. Commits don't. This is how you ship deterministic plugins across a 5,000-engineer org without one dev accidentally upgrading to a broken version during a release freeze.

Release channels work the same way — keep two marketplaces (acme-tools-stable, acme-tools-canary) pointing at different branches with distinct pinned SHAs. Developers opt into canary. Everyone else stays on stable.

The Lockdown: strictKnownMarketplaces

This is the setting that separates hobbyist from enterprise. In your org's managed settings:

{
  "strictKnownMarketplaces": [
    {"source": "github", "repo": "acme-corp/approved-plugins"},
    {"source": "hostPattern", "hostPattern": "^github\\.acme-corp\\.com$"}
  ]
}

Empty array = lockdown, no third-party marketplaces. A list = allowlist. A hostPattern regex = domain-level control. Pair with extraKnownMarketplaces to auto-inject your corporate marketplace so engineers don't have to discover or configure it.

Without this, any employee can run /plugin marketplace add random-internet-person/totally-safe-plugins and suddenly you have unreviewed scripts running with their local credentials, SSH keys, and AWS tokens. The technical capability is identical to the company marketplace. The governance is what changes.

Hooks Are the Runtime Enforcement Layer

Marketplaces control what gets installed. Hooks control what happens at runtime.

PreToolUse hooks fire before any tool call. They receive JSON on stdin describing the call, and can exit 0 (allow), non-zero (block), or rewrite the tool arguments. This is where you enforce org policy at execution time — not just installation time.

Real examples worth shipping in your internal plugin:

• Block Bash calls containing curl | sh patterns
• Reject Edit/Write to ~/.aws/credentials, ~/.ssh/id_*, or /etc/
• Require human approval for MCP calls to external APIs
• Log every filesystem mutation to a central audit service

The marketplace decides which plugins your team can install. The hooks decide what those plugins can actually do once loaded. You need both.

What Most Orgs Will Get Wrong

Mistake #1: Private repo as marketplace. Putting a skills/ directory in a private GitHub repo and asking people to clone it. That skips the marketplace.json layer entirely — no version pinning, no managed-settings enforcement, no clean update mechanism. Works for 5 people. Breaks at 500.

Mistake #2: Trusting the public directory. Anthropic's claude-plugins-official is curated, but "curated" is not "audited for your security posture." The 72+ community plugins have zero security review from anyone. Don't install these org-wide based on install counts.

Mistake #3: Forgetting the seed directory. For air-gapped environments or CI containers, CLAUDE_CODE_PLUGIN_SEED_DIR lets you bake plugins into the image at build time. Skip it and your CI pipelines hit GitHub every run — network errors, rate limits, surprise outages when Microsoft-owned infrastructure blips.

Mistake #4: Treating security as a scanning problem. There's no binary signing for Claude plugins in 2026. Static analysis catches obvious issues; it won't catch a plugin that calls an LLM to generate malicious commands at runtime. Your defense is the marketplace allowlist + runtime hooks + human code review before plugins enter the marketplace. Not automated scanners.

The First-Week Setup

If you're standing up an enterprise marketplace this quarter:

1. Two repos, separated. acme-plugins-marketplace (just marketplace.json and approval metadata) and your actual plugin source repos. Separating manifest from code lets you revise approval lists without touching plugin internals.

2. Write a managed-settings policy. Lock strictKnownMarketplaces to your corporate marketplace. Ship via your MDM or config-management tool (Ansible, Jamf, Chef, whatever already provisions dev laptops).

3. Start with three plugins. Something low-risk (commit-message helper), something internal-facing (your SSO login flow), something domain-specific (your SOW template for client work). Three forces you to confront versioning, namespacing, and review questions before you scale.

4. Ship a PreToolUse audit hook on day one. Even if it just logs. Retrofitting observability onto 50 plugins later is miserable.

5. Document the review process. Who reviews? What's the bar? What gets rejected? Most orgs skip this and end up with approval-by-loudest-voice. Write it down before you take the first submission.

The tools are ready. The distribution mechanism is solved. What's left is organizational work — deciding who decides, and who's accountable when a plugin ships something stupid.