Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix /plugin install <name>@<marketplace> ignores marketplace suffix when name exists in another marketplace [1 comments, 2 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#52270•Fetched 2026-04-24 06:11:37
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Author
djoneverettdjoneverett
Participants
djoneverettdjoneverettgithub-actions[bot]github-actions[bot]
Timeline (top)
labeled ×4commented ×1

/plugin install <name>@<marketplace> installs from the wrong marketplace when the plugin name also exists in another registered marketplace. The @<marketplace> suffix appears to be decorative — resolution is purely by plugin name, and the default/first marketplace wins.

Root Cause

After manually renaming the registry key to remember@dpt-plugins and moving the files, /reload-plugins re-creates the cache/claude-plugins-official/remember/<version>/ dir, presumably because the Anthropic marketplace's catalog still lists the plugin. The orphan dir then accumulates on every reload.

RAW_BUFFERClick to expand / collapse

Summary

/plugin install <name>@<marketplace> installs from the wrong marketplace when the plugin name also exists in another registered marketplace. The @<marketplace> suffix appears to be decorative — resolution is purely by plugin name, and the default/first marketplace wins.

Repro

  1. Register two marketplaces that both catalog a plugin with the same name. Example:
    • claude-plugins-official (auto-registered) catalogs remember.
    • /plugin marketplace add Digital-Process-Tools/claude-marketplace (also catalogs remember).
  2. Run /plugin install remember@dpt-plugins.
  3. Inspect ~/.claude/plugins/installed_plugins.json.

Expected

Registry key: remember@dpt-plugins Install path: ~/.claude/plugins/cache/dpt-plugins/remember/<version>/

Actual

Registry key: remember@claude-plugins-official Install path: ~/.claude/plugins/cache/claude-plugins-official/remember/<version>/

Content is fetched from the correct upstream repo (same commit SHA either way), but the marketplace attribution is wrong, so /plugin marketplace update subsequently routes through the unintended marketplace.

Related: speculative re-clone on reload

After manually renaming the registry key to remember@dpt-plugins and moving the files, /reload-plugins re-creates the cache/claude-plugins-official/remember/<version>/ dir, presumably because the Anthropic marketplace's catalog still lists the plugin. The orphan dir then accumulates on every reload.

Repro attempted with fully scrubbed state

  • Uninstalled the plugin via /plugin UI.
  • Removed the DPT marketplace via /plugin marketplace remove dpt-plugins.
  • Manually deleted cache/<marketplace>/remember/ directories and marketplaces/dpt-plugins/.
  • Verified installed_plugins.json had no remember entry and known_marketplaces.json had no dpt-plugins entry.
  • Re-added DPT marketplace and ran /plugin install remember@dpt-plugins.

Result: same incorrect namespace attribution.

Environment

extent analysis

TL;DR

The issue can be mitigated by ensuring unique plugin names across registered marketplaces or by modifying the plugin installation process to prioritize the specified marketplace.

Guidance

  • Verify that the @<marketplace> suffix is correctly handled in the plugin installation code to ensure it's not purely decorative.
  • Check the logic for resolving plugin names to marketplaces, ensuring it doesn't default to the first registered marketplace when a plugin name exists in multiple marketplaces.
  • Consider implementing a mechanism to handle plugin name conflicts across marketplaces, such as prompting the user to select the intended marketplace or automatically appending a unique identifier to the plugin name.
  • Review the /plugin marketplace update routing logic to ensure it uses the correct marketplace based on the installed plugin's registry key.

Example

No code snippet is provided due to the lack of specific implementation details in the issue.

Notes

The issue seems to stem from the plugin installation process not correctly handling the @<marketplace> suffix, leading to incorrect marketplace attribution. Without access to the underlying code, it's challenging to provide a definitive fix. However, ensuring unique plugin names or modifying the installation process to prioritize the specified marketplace should mitigate the issue.

Recommendation

Apply a workaround by ensuring unique plugin names across registered marketplaces, as this is a more feasible solution given the current information.

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…
#GPU setup#container setup#orchestration issue#cache issue#memory leak

Still need to ship something?

×6

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

Back to top recommendations

TRENDING