[FEATURE] Allow plugins to restrict install --scope via plugin.json

Resolved 💬 1 comment Opened May 7, 2026 by rulyone Closed Jun 11, 2026

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

I author plugins for a marketplace. Some are designed only for project-level use — for example, threejs-skills, which auto-loads ten Three.js skills (geometry, materials, shaders, etc.) into context.

Today, install scope is chosen entirely by the user. The CLI prompts interactively to pick user, project, or local, and the plugin author has no way to express that some scopes don't make sense for their plugin. This causes two problems:

  1. Context bloat. If a user picks user scope, all ten Three.js skills load in every Claude Code session — including projects with nothing to do with Three.js. Even if it's only the description loaded, it discourages plugins to have multiple single responsibility skills for wider stacks, or enforces a parent skill with references to children skills.
  2. Author intent isn't enforceable. A skills pack tuned to one stack only makes sense inside a repo using that stack. README wording is the only "enforcement" today, and users skim past it.
  3. Accidental skill activation. Even if it's just 1 skill, it could be activated by accident given some keyword overlap in the description.

Proposed Solution

Add an optional install block to plugin.json:

{
  "name": "threejs-skills",
  "install": {
    "allowedScopes": ["project", "local"]
  }
}

Behavior:

  • Field absent → unchanged (backward compatible).
  • The interactive scope prompt only shows allowed scopes. If only one scope is allowed, skip the prompt entirely.
  • claude plugin install foo --scope user with a disallowed scope fails fast with:

``
Error: plugin "threejs-skills" does not allow --scope user.
Allowed scopes: project, local.
``

  • Allowlist (not blocklist) so future scopes don't silently expand a plugin's footprint.
  • Lives in plugin.json so the constraint travels with the plugin across marketplaces.

Alternative Solutions

"recommend" plugin scope on install when plugin has metadata similar to original proposal.

Priority

High - Significant impact on productivity

Feature Category

Developer tools/SDK

Use Case Example

I would use this feature on tech-stack specialized skills to prevent context bloat and user miss-use.

Additional Context

_No response_

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗