Plugin install/uninstall state gets corrupted across git worktrees (duplicate installed_plugins.json entries, contradictory uninstall/disable errors)

Summary

Installing a plugin (figma@claude-plugins-official) from multiple git worktree checkouts of the same repo caused ~/.claude/plugins/installed_plugins.json to accumulate duplicate/stale entries for that plugin. Once duplicated, claude plugin uninstall / claude plugin disable (both CLI and the /plugin GUI trash button) gave contradictory errors that made cleanup impossible through any supported path.

Environment

• OS: Windows 11 Pro (10.0.22621)
• Setup: two git worktree checkouts of the same repository (different directories, different branches)
• Plugin: figma@claude-plugins-official (official marketplace), but the underlying mechanism looks plugin-agnostic

Steps to reproduce

1. In worktree A, run claude plugin install figma@claude-plugins-official (project scope, default).
2. In worktree B (separate worktree of the same repo), run claude plugin install figma@claude-plugins-official again, more than once within a short window (e.g. re-running the onboarding command a couple of times).
3. Also install at user scope: claude plugin install figma@claude-plugins-official --scope user.
4. Inspect ~/.claude/plugins/installed_plugins.json → the figma@claude-plugins-official key now holds 4 array entries. Two of them are exact duplicates: same scope: "project", same projectPath, same version, installedAt timestamps ~1 minute apart.
5. /plugin → Installed tab shows figma@claude-plugins-official listed 4 separate times.
6. Attempt cleanup via CLI:

``
claude plugin uninstall figma@claude-plugins-official --scope project
`
This succeeds once (removes one duplicate), but running the *exact same command again in the same directory* fails with:
`
✘ Failed to uninstall plugin "figma@claude-plugins-official": Plugin "figma@claude-plugins-official" is installed in user scope, not project. Use --scope user to uninstall.
`
even though installed_plugins.json still contains a scope: "project" entry with a projectPath` matching the current directory.

1. Attempt cleanup via the /plugin GUI instead: deleting the user-scope entry causes the remaining project-scope entries to flip to "disabled". Deleting either remaining entry then fails with:

``
Claude CLI exited with code 1: × Failed to uninstall plugin "figma@claude-plugins-official": Plugin "figma@claude-plugins-official" is enabled at project scope (.claude/settings.json, shared with your team). To disable just for you: claude plugin disable figma@claude-plugins-official --scope local
``

1. Following the suggested fix produces a contradictory error for the exact same plugin/directory:

``
claude plugin disable figma@claude-plugins-official --scope local
✘ Failed to disable plugin "figma@claude-plugins-official": Plugin "figma@claude-plugins-official" is already disabled at local scope
``
So the tool simultaneously claims the plugin is "enabled at project scope" (blocking uninstall) and "already disabled at local scope" (blocking the suggested remedy). This loop persisted across a full Claude Code restart and an OS reboot.

Suspected root cause

• claude plugin install does not appear to dedupe/upsert against an existing {scope, projectPath} record in installed_plugins.json — each invocation appends a new array element, so repeated installs (re-running onboarding, installing separately per worktree, etc.) accumulate indefinitely.
• The "is this plugin enabled at project scope" check used by uninstall/disable appears to key off presence of the enabledPlugins["<plugin>"] key in the project's .claude/settings.json, rather than its boolean value. A project .claude/settings.json containing "figma@claude-plugins-official": false was reported as "enabled at project scope" and blocked uninstall, despite the value being explicitly false.

Workaround

Backed up and manually edited ~/.claude/plugins/installed_plugins.json to delete the stray/duplicate array entries for the plugin, then ran claude plugin install figma@claude-plugins-official once more to get a single clean scope: "user" entry. No supported CLI or GUI path reached this state without manual file editing.

Impact

No data loss, but the CLI/GUI cleanup attempts (including a wrong-direction fix suggested by the tool's own error message) cost significant troubleshooting time before falling back to manually editing internal state — which shouldn't be necessary for cleaning up a duplicated plugin listing.