[BUG] plugin uninstall resolves by bare name, can silently uninstall an unrelated enabled plugin sharing the same name in a different marketplace

Description

claude plugin uninstall <id> resolves plugins by bare name internally in at least one code path, even when the caller passes a fully-qualified plugin@marketplace id. When two different marketplaces each have an installed plugin sharing the same short name, uninstalling the disabled one by its fully-qualified id can silently uninstall the other, unrelated, enabled plugin instead — while leaving the intended target still installed.

Environment

• claude --version: 2.1.205
• macOS

Repro

Two plugins named superpowers were installed at user scope, from two different marketplaces:

{
  "id": "superpowers@claude-plugins-official",
  "version": "6.1.1",
  "scope": "user",
  "enabled": false
}

{
  "id": "superpowers@superpowers-marketplace",
  "version": "5.1.0",
  "scope": "user",
  "enabled": true
}

Ran:

claude plugin uninstall superpowers@claude-plugins-official -s user --keep-data -y

Output:

✔ Successfully uninstalled plugin: superpowers (scope: user)

(Note the success message drops the marketplace qualifier entirely — only prints the bare name, which is what tipped me off to the likely root cause.)

Expected

Only superpowers@claude-plugins-official is removed from ~/.claude/plugins/installed_plugins.json / claude plugin list --json. superpowers@superpowers-marketplace (enabled, different marketplace, different install path/version) is untouched.

Actual

claude plugin list --json immediately after the command showed:

• superpowers@claude-plugins-official — still present, still enabled: false (the intended target was never actually removed)
• superpowers@superpowers-marketplace — gone entirely from the list (not just disabled — fully uninstalled, dropped from installed_plugins.json)

This was a real, enabled, actively-used plugin (invoked dozens of times/month in this account's usage history) that got silently removed as a side effect of uninstalling an unrelated, disabled, same-named plugin from a different marketplace.

Workaround / recovery

claude plugin enable superpowers@superpowers-marketplace -s user re-triggered a full reinstall (fresh fetch from the marketplace source, since it had been fully uninstalled rather than just disabled) and restored it correctly.

Impact / why this matters

This happened while batch-uninstalling ~83 disabled, zero-usage plugins from claude-plugins-official to shrink /context's skill catalog footprint (a large fraction of installed marketplace plugins were disabled-but-never-uninstalled, each still contributing "always-on" token cost per claude plugin details — a separate but related discoverability gap worth its own docs note: disable does not remove a plugin's contribution to context token cost, only uninstall does). In a batch operation over dozens of plugins, this bug is easy to trigger blind (any bare-name collision across two installed marketplaces) and easy to miss (the CLI reports success either way, and the collateral damage is a different plugin than the one targeted — nothing in the uninstall output or exit code signals anything went wrong).

Suggested fix: uninstall (and likely enable/disable) should resolve strictly by the fully-qualified plugin@marketplace id end-to-end, never falling back to/matching on bare name once a marketplace qualifier is provided. At minimum, the success message should always echo the fully-qualified id that was actually acted on, so this kind of mismatch is visible immediately.