[FEATURE] Add a path field to GitHub plugin sources in the Claude Plugin Marketplace

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

In an enterprise environment, we want to manage Claude plugins and marketplaces via an allowlist for governance and security. However, many third-party marketplaces are published as open source, and it has become a de facto practice for users to add arbitrary third-party marketplaces. This creates governance gaps and makes it difficult for system administrators to control which plugins are available within the organization.

We want a single, official, company-managed marketplace (hosted in our GitHub organization) that lists approved plugins—both third-party and internal—while allowing us to pin plugin versions to immutable commit SHAs for security best practices.

Today, the GitHub plugin source configuration lacks a way to specify a plugin located in a subdirectory of a repository (i.e., no path for plugin sources), which prevents us from centrally managing approved plugins that live under specific repo paths.

Proposed Solution

Extend the plugin source schema so that GitHub plugin sources support an additional field:

• path (string): subdirectory within the GitHub repository where the plugin lives

This would allow a company-managed marketplace.json to reference:

1. Approved plugins that exist in a subdirectory of a third-party repository
2. Internal plugins hosted in subdirectories of internal repositories

…all within a single marketplace file, while also pinning each plugin to a fixed sha to prevent unexpected changes that can occur with mutable refs (tags/branches).

Alternative Solutions

_No response_

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

Company-managed marketplace hosted at: https://github.com/<company-organization>/claude-plugins

1) Approving a third-party plugin from a subdirectory (with SHA pinning)

{
  "name": "company-claude-plugins",
  "plugins": [
    {
      "name": "typescript-lsp",
      "source": {
        "source": "github",
        "repo": "anthropics/claude-plugins-official",
        "path": "plugins/typescript-lsp",
        "sha": "abc123"
      }
    }
  ]
}

2) Approving an internal plugin hosted in a subdirectory (with SHA pinning)

{
  "name": "company-claude-plugins",
  "plugins": [
    {
      "name": "marketing-email-sender",
      "source": {
        "source": "github",
        "repo": "<company-organization>/marketing",
        "path": "email/plugins/email-sender",
        "sha": "abc123"
      }
    }
  ]
}

Recommended operational model

1. System admins distribute managed settings via MDM to allow only https://github.com/<company-organization>/claude-plugins.git using strictKnownMarketplaces.
2. Plugin admins update the company marketplace’s marketplace.json to control the approved plugin list (repo + path + name + sha).
3. End users run /plugin marketplace update to fetch the latest approved marketplace, then /plugin install to install approved plugins.

This enables strong governance (single allowed marketplace), delegated plugin administration, and secure version control via immutable SHA pinning.

Additional Context

• GitHub source
• strictKnownMarketplaces