claude-code - 💡(How to fix) Fix [BUG] /plugin lists user-scope plugins under "Project" tab, blocks disable without --scope user

Preflight Checklist

• 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)
• This is a single bug report
• 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:

1. cd ~/dev (a directory whose .claude/settings.json has no enabledPlugins).
2. Launch Claude Code, run /plugin.
3. Observed: the same plugin list shown at user scope is duplicated under the Project tab/heading.
4. 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:

1. Don't show user-scope plugins under "Project" when the project's effective enabledPlugins is empty. Project tab should reflect origin scope (where the entry actually lives on disk), not effective scope (what's active in this folder).
2. 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)

1. ~/.claude/settings.json contains "enabledPlugins": { "<some-plugin>@<marketplace>": true }.
2. Create or cd into a folder containing .claude/settings.json without an enabledPlugins key. The directory's .claude.json projects entry must also lack enabledPlugins.
3. Run claude then /plugin.
4. Observe: user-scope plugins appear under the Project tab.
5. 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 under enabledPlugins to false.

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 — /plugin enable/disable always writes to user scope (closed 2026-01-11)
• #16260 — claude plugin uninstall contradictory 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.