[BUG] Plugin management is broken in several connected ways (scope flag, UI writes to wrong scope, silent load failures, duplicate entries)
I spent a good chunk of time today trying to move two plugins from global scope to project scope, and ran into four separate issues that compounded each other. Documenting them all here since they're related and together make plugin scope management basically unusable.
Environment
- Claude Code VSCode extension (2.1.190)
- Windows 11 Enterprise 10.0.26200
---
Bug 1: --scope local is suggested by the CLI but doesn't actually exist
When you try to uninstall a locally-scoped plugin without the flag, the error message tells you to use --scope local:
Plugin "engineering@knowledge-work-plugins" is installed in local scope, not user. Use --scope local to uninstall.
So you run exactly what it says:
claude plugin uninstall engineering@knowledge-work-plugins --scope local
error: unknown option '--scope'
The CLI is recommending a flag that doesn't exist. You're stuck — there's no working CLI path to uninstall a locally-scoped plugin.
---
Bug 2: The Manage Plugins UI toggle always writes to global settings, ignoring the open project
When you open a project in VSCode and toggle a plugin on via the Manage Plugins panel, the entry lands in ~/.claude/settings.json (user/global scope), not in the project's .claude/settings.json. There's no way through the UI to enable a plugin at project scope only.
Steps to reproduce:
- Open any project in VSCode with the Claude Code extension
- Open Manage Plugins and toggle any plugin on
- Check
~/.claude/settings.json— the entry is there - Check
.claude/settings.jsonin your project — nothing was written
This means every plugin you enable via the UI becomes global, which is not what you want if you're trying to keep plugin sets per-project.
---
Bug 3: Enabling a plugin in project settings silently does nothing if it wasn't installed in that project
This one was the most confusing. The plugin system has two independent mechanisms: enabledPlugins in settings files, and an install registry at ~/.claude/plugins/installed_plugins.json. For a plugin to actually load its skills, it needs to be in both, with a matching projectPath. If you manually add a plugin to a project's enabledPlugins but it was originally installed in a different project, the plugin shows a green dot in the UI but its skills never load — and there's no error message anywhere explaining why.
Steps to reproduce:
- Install plugin X while in Project A —
installed_plugins.jsonrecordsprojectPath: A - Add plugin X to
enabledPluginsin Project B's.claude/settings.jsonmanually - Reload the extension — plugin X shows a green dot in the Manage Plugins UI for Project B
- Try to use any of plugin X's skills — they're not there, nothing loads, no error shown
I only figured this out by reading installed_plugins.json directly. There should be either an automatic fix (create the install record when the plugin is cached and referenced) or at minimum a visible error explaining the mismatch.
---
Bug 4: Installing a plugin in multiple projects creates duplicate rows in the Manage Plugins UI
Once I manually added install records for both projects (the only workaround for Bug 3), the Manage Plugins UI started showing the same plugin twice — one row per install record, with no label indicating which row belongs to which project. This happened in both projects.
Steps to reproduce:
- Install plugin X in Project A
- Install plugin X in Project B (or manually add a second entry to
installed_plugins.json) - Open Manage Plugins in either project — plugin X appears twice in the INSTALLED list
---
How these bugs interact
Starting point: I wanted plugins enabled only in Project B, not globally.
- Tried the CLI uninstall → Bug 1 (flag doesn't exist)
- Tried manually editing settings → works, but...
- Plugin shows green but skills don't load → Bug 3 (install registry mismatch, no error)
- Fixed by editing
installed_plugins.jsondirectly → Bug 4 (now duplicates in UI) - Throughout: UI toggle would have fixed it but always writes globally → Bug 2
Each bug is independently annoying. Together they make it effectively impossible to manage plugin scope without manually editing internal JSON files.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗