claude-code - 💡(How to fix) Fix Project-scope plugin auto-discovery from <cwd>/.claude/plugins/*/ [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#57929Fetched 2026-05-11 03:21:40
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Participants
Timeline (top)
labeled ×2

Support auto-discovery of project-scope plugins in <cwd>/.claude/plugins/*/plugin.json, without requiring a marketplace wrapping. Equivalent semantics to running claude plugin install <path> --scope project implicitly when the directory exists at startup.

Root Cause

Support auto-discovery of project-scope plugins in <cwd>/.claude/plugins/*/plugin.json, without requiring a marketplace wrapping. Equivalent semantics to running claude plugin install <path> --scope project implicitly when the directory exists at startup.

Fix Action

Fix / Workaround

  • ParisGroup uses claude-devkit to manage per-repo filtered views across ~10 repos.
  • Plan 5 dogfooding (May 2026) revealed that local-path installs at project scope are rejected by CC 2.1.138 — "not found in any configured marketplace".
  • Plan 6 ships a wrapping-marketplace workaround (linked above) but it is noticeable complexity (~150 LOC + 4 doctor checks + 4 real-cc smoke fixtures). Auto-discovery would let us delete most of it.
RAW_BUFFERClick to expand / collapse

Summary

Support auto-discovery of project-scope plugins in <cwd>/.claude/plugins/*/plugin.json, without requiring a marketplace wrapping. Equivalent semantics to running claude plugin install <path> --scope project implicitly when the directory exists at startup.

Use case

Tools like claude-devkit generate filtered plugin views per-repo (a subset of skills/commands/agents from upstream plugins, plus the consuming repo's own assets). With CC 2.x's current model, this requires:

  1. Generate the view as a directory tree.
  2. Generate a wrapping marketplace.json that lists the view as a plugin.
  3. Run claude plugin marketplace add + install + update per regeneration, re-stamping a content-hash version into the marketplace.json so CC re-caches.

If CC auto-discovered <cwd>/.claude/plugins/<name>/plugin.json directly, devkit (and similar tools) could write the view and stop — no marketplace plumbing, no content-hash dance.

Suggested behavior

  • On CC startup (or workspace-open), scan <cwd>/.claude/plugins/*/plugin.json.
  • For each match, load the plugin in-place from that directory (no copy to cache).
  • Behave equivalent to claude plugin install --scope project for discovery, load order, and claude plugin list output.
  • File-watch the directory: hot-reload on change.

Migration path for tool authors

A tool that ships wrapping marketplaces today can detect CC version ≥ X (the one with auto-discovery) and skip the wrapping plumbing. Backwards-compat path stays trivial.

Why not just symlinks / hot-reload the current cache?

Tried (Plan 6 Option 2 in our design doc). Brittle: CC update overwrites symlinks. Cache is canonical, source dir is not. Auto-discovery would flip the canonical location to the source dir itself.

Context

  • ParisGroup uses claude-devkit to manage per-repo filtered views across ~10 repos.
  • Plan 5 dogfooding (May 2026) revealed that local-path installs at project scope are rejected by CC 2.1.138 — "not found in any configured marketplace".
  • Plan 6 ships a wrapping-marketplace workaround (linked above) but it is noticeable complexity (~150 LOC + 4 doctor checks + 4 real-cc smoke fixtures). Auto-discovery would let us delete most of it.

We also discovered along the way (CC 2.1.138):

  • claude plugin list does not accept --scope — needed to add a client-side filter.
  • CC registers managed views under the marketplace-namespaced id <plugin-name>@<marketplace-name>, not the bare <plugin-name>.
  • marketplace.json source is resolved relative to the parent of the marketplace.json directory (installLocation), not the directory containing it.

If any of those are documented somewhere we missed, a pointer would help. Happy to chat through implementation specifics or beta-test if you ship the auto-discovery feature.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix Project-scope plugin auto-discovery from <cwd>/.claude/plugins/*/ [1 participants]