[FEATURE] Cross-marketplace plugin references (proxy entries)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Organizations maintaining multiple repos often want a single marketplace as the entry point for all their plugins. But some plugins live in their own dedicated repos (with their own marketplaces), while others are small enough to live directly in the central marketplace.

Today there's no way for a marketplace plugin entry to reference a plugin from another marketplace. The available workarounds all have significant drawbacks:

Option A: Git remote source — Use "source": { "source": "github", "repo": "org/other-repo" } in the central marketplace.

• Clones the entire target repo just to extract the plugin files. This is disproportionate when the repo is a full application (backend, infra, tests, etc.) and the plugin is a handful of .md agent files.

Option B: Vendoring — Copy plugin files into the central marketplace repo.

• Files are duplicated across repos. Requires manual sync or CI automation (repository_dispatch) to keep them in sync. Drift is inevitable.

Option C: Separate marketplaces — Give up on centralization. Users add each marketplace individually.

• No single entry point. New team members must know which marketplaces to add. Onboarding friction.

Proposed Solution

Allow marketplace plugin entries to reference a plugin from another marketplace by name:

{
  "name": "acme-plugins",
  "plugins": [
    {
      "name": "say-done",
      "source": "./plugins/say-done",
      "description": "Says done aloud when Claude finishes a task"
    },
    {
      "name": "acme-agents",
      "source": { "marketplace": "acme-agents", "plugin": "acme-agents" },
      "description": "Internal workflow agents"
    }
  ]
}

When a user installs acme-agents@acme-plugins:

1. Claude Code resolves the reference to the acme-agents marketplace
2. Fetches/clones only that marketplace's repo (which IS the plugin)
3. Installs the plugin as if the user had run claude plugin install acme-agents@acme-agents

The central marketplace acts as a catalog — it knows what plugins exist and where they live, but doesn't need to contain their files.

Shorthand when the plugin name matches:

{
  "name": "acme-agents",
  "source": { "marketplace": "acme-agents" },
  "description": "Internal workflow agents"
}

Alternative Solutions

1. Sparse checkout for git sources — Instead of cloning the entire repo, allow source to specify a subdirectory: { "source": "github", "repo": "org/repo", "path": "plugins/my-plugin" }. This would mitigate the "clones entire repo" problem but doesn't eliminate it. Complementary improvement.

1. Auto-add dependent marketplaces — A marketplace could declare "requires": ["acme-agents", "acme-knowledge"] and Claude Code would auto-register those marketplaces when the parent is added. Lighter than full proxy entries but still gives a single onboarding command.

1. Marketplace bundles / meta-marketplaces — A marketplace type that only contains references to other marketplaces, acting purely as an aggregator. Running /plugin marketplace add org/hub would register all referenced marketplaces. Simpler than per-plugin proxying.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

An organization has:

• org/claude-plugins — central marketplace with small utility plugins (notification hooks, sounds)
• org/framework — full repo with its own marketplace containing agents, commands, and skills
• org/knowledge — full repo with its own marketplace containing knowledge graph plugins

They want new team members to run one command:

/plugin marketplace add org/claude-plugins

And from there discover and install everything — including framework and knowledge plugins — without needing to know about the individual repos. Today this is impossible without vendoring (duplicating files) or cloning entire application repos.

Additional Context

Related issues:

• #9444 — Plugin dependencies and shared resources (complementary: about plugin-to-plugin dependencies, this is about marketplace-to-marketplace references)
• #21370 — Bulk install all plugins from a marketplace (complementary: would combine well with a central catalog marketplace)