[BUG] /plugin lists user-scope plugins under "Project" tab, blocks disable without --scope user
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet (closest matches #9533 and #16260 are both auto-closed stale; neither covers the listing-side mislabel)
- [x] This is a single bug report
- [x] I am using the latest version of Claude Code (2.1.131)
What's Wrong?
/plugin mislabels user-scope plugins as project-scope in its TUI listing whenever the current working directory has any .claude/ directory present, even when that directory contains zero plugin configuration. Disable from the misleading "Project" listing then fails — operator must invoke with --scope user to actually disable.
Reproduction
Setup (verified on my machine):
~/.claude/settings.json contains:
"enabledPlugins": {
"commit-commands@claude-plugins-official": true,
"ralph-loop@claude-plugins-official": true,
"github@claude-plugins-official": true,
"...": "..."
}
~/dev/.claude/settings.json contains hooks + permissions only — no enabledPlugins key:
{
"hooks": { "PreCompact": [...], "SessionStart": [...] },
"permissions": { "additionalDirectories": [...], "allow": [...] }
}
~/.claude.json projects["C:/Users/<user>/dev"] entry — also no enabledPlugins key (verified via node -e JSON inspection of all 37 project entries).
Steps:
cd ~/dev(a directory whose.claude/settings.jsonhas noenabledPlugins).- Launch Claude Code, run
/plugin. - Observed: the same plugin list shown at user scope is duplicated under the Project tab/heading.
- Attempt to disable any of those plugins from the project listing → fails / no-ops without
--scope user.
What Should Happen?
Two correct behaviors, either acceptable:
- Don't show user-scope plugins under "Project" when the project's effective
enabledPluginsis empty. Project tab should reflect origin scope (where the entry actually lives on disk), not effective scope (what's active in this folder). - Track origin scope through the disable flow so that disabling from any listing context routes the write to the file that actually contains the entry.
The current behavior conflates "this plugin is active in your current folder" with "this plugin is configured at project scope" — those are not the same thing when project scope is empty and the user-scope entries are simply visible here.
Why this matters
Operators see plugins in the Project tab and reasonably try to disable them at project scope (e.g., to turn one off for one repo only). The disable silently does nothing visible, the plugin stays enabled, and there's no clear UI signal that the entry actually lives at user scope. Workaround (--scope user) requires CLI knowledge that the TUI doesn't surface.
This is the listing-side analog of the write-side bug reported in #9533 (auto-closed stale) and the contradictory-scope-errors bug in #16260 (auto-closed stale). Both were closed without fix; the underlying scope-resolution logic still appears to conflate origin and effective scope.
Steps to Reproduce (minimal)
~/.claude/settings.jsoncontains"enabledPlugins": { "<some-plugin>@<marketplace>": true }.- Create or
cdinto a folder containing.claude/settings.jsonwithout anenabledPluginskey. The directory's.claude.jsonprojects entry must also lackenabledPlugins. - Run
claudethen/plugin. - Observe: user-scope plugins appear under the Project tab.
- Attempt to disable one from the Project tab → no effect; requires
--scope user.
Workaround
Either:
claude /plugin --scope user disable <plugin>@<marketplace>, OR- Hand-edit
~/.claude/settings.json, flip the entry underenabledPluginstofalse.
Claude Code Version
2.1.131 (Claude Code)
Platform
Anthropic API
Operating System
Windows 11 Pro 10.0.26200 (also reported on Linux in the related #9533)
Terminal/Shell
Windows Terminal / PowerShell 7+
Additional Information
Both prior related issues were closed by github-actions[bot] as stale or not_planned:
- #9533 —
/pluginenable/disable always writes to user scope (closed 2026-01-11) - #16260 —
claude plugin uninstallcontradictory scope errors (closed 2026-02-28)
Filing this fresh because it's a distinct surface (listing/labeling, not write routing) and because the prior issues were never actually resolved before being autoclosed.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗