Claude Codeのプラグインがグローバル誤検知される問題と対処法
プロジェクトスコープでインストールしたプラグインが別プロジェクトでも「インストール済み」と誤表示され、再インストールできなくなる既知の不具合と回避策をまとめます。
--scope projectでインストールしたプラグインを、別のプロジェクトで開くと「インストール済み」の印が付きます。それでいて再インストールはできず、/pluginのInstalledタブには表示もされません。この食い違いは、GitHubで20件のコメントが付いている既知の不具合です。プロジェクトごとにプラグインを切り替えたい構成、特にモノレポや複数リポジトリを並行して触る運用ほど直撃します。原因と、コミュニティで確認されている回避策をまとめます。
症状 — 別プロジェクトで「インストール済み」と表示され再インストールできない
不具合はGitHubのissue #14202として、2025年12月16日に報告されました。再現手順は次の流れです。
- プロジェクトAで、ローカルのマーケットプレイスからプラグインをプロジェクトスコープでインストールする
- プロジェクトAの
/pluginのInstalledタブでプラグインが正しく表示されることを確認する - 別ディレクトリのプロジェクトBでClaude Codeを開き、
/pluginのMarketplacesタブを見る - 期待する挙動は「未インストールとして表示され、選べば入れられる」ことである
- 実際にはチェックマーク付きで「(installed)」と表示され、選んでもインストールできない
- それでいてプロジェクトBのInstalledタブを見ると、プラグインは表示されない
最後の6番目が手がかりです。InstalledタブだけはprojectPathで正しくフィルタされているため、表示が食い違います。
報告時点のバージョンは2.0.70でした。その後、Arch LinuxやmacOSといった複数の実行環境で同様の報告が続いています。対象もコミュニティ製プラグインに限らず、claude-plugins-official配下の公式プラグイン(pr-review-toolkitなど)にも及んでいます。特定の環境やマーケットプレイスに限った問題ではないということです。issueに2026年3月12日に投稿された最新コメントの時点でも、複数の利用者から解決を求める声が続いていました。
原因 — 3つの操作でprojectPathの扱いが揃っていない
issueのRoot Cause Analysisによれば、プラグインのインストール状態を確認する3つの操作のあいだでprojectPathのチェック有無が揃っていないことが原因です。projectPathは、そのプラグインがどのプロジェクトに紐づくかを示す内部の値です。
| 操作 | projectPathを見るか | 実際の挙動 |
|---|---|---|
| Marketplacesタブの「(installed)」表示 | projectPathを見るか見ていない | 実際の挙動どのプロジェクトからでもグローバルにインストール済み扱いになる |
/plugin install / claude plugin install | projectPathを見るか見ていない | 実際の挙動レジストリにキーが存在するだけで「既にインストール済み」と判定し拒否する |
| Installedタブの一覧表示 | projectPathを見るか見ている | 実際の挙動現在のプロジェクトに紐づくものだけを正しく絞り込む |
レジストリファイル~/.claude/plugins/installed_plugins.json自体は、プロジェクトスコープのインストールごとにprojectPathを正しく記録しています。問題はMarketplacesタブとインストールコマンドの側にあります。どちらもJSON内に「プラグインキーが存在するかどうか」しか見ておらず、「現在のプロジェクトに対して」インストール済みかを見ていません。このファイルのスキーマは公式ドキュメントで仕様化されていないため、issueに投稿された実物のJSON構造が読み解く手がかりになります。
自分の環境で再現するか確認する
回避策を試す前に、まず自分の環境でこの不具合に当たっているかを確認できます。issueのコメントでもinstalled_plugins.jsonの中身を根拠に切り分けが行われています。
cat ~/.claude/plugins/installed_plugins.json | grep -A3 "対象プラグイン名"出力にprojectPathが含まれ、それが今開いているプロジェクトとは別のパスを指していれば、この不具合に該当しています。エントリ自体が見当たらない場合は、別の原因(マーケットプレイスの未追加やキャッシュ破損など)を先に疑う方が近道です。
回避策 — レジストリと設定ファイルを手動で合わせる
issueのコメントで複数の利用者が確認している回避策は、レジストリファイルと設定ファイルの両方を手作業で新しいプロジェクト向けに揃える方法です。公式のサブコマンドではなく、Claude Codeが内部で使っているファイルを直接編集する点は踏まえておく必要があります。
# 対象プロジェクトのディレクトリで settings.json を確認・作成する
cat .claude/settings.json.claude/settings.jsonに、対象プラグインのenabledPluginsエントリを追加します。キーの形式はplugin-name@marketplace-nameです。これは設定リファレンスが定める正式な仕様どおりです。
{
"enabledPlugins": {
"my-plugin@my-marketplace": true
}
}続けて~/.claude/plugins/installed_plugins.jsonのプラグインエントリに、新しいプロジェクトのprojectPathを追加します。issueに投稿された実例では、既存エントリの配列に要素を1件追加する形が使われています。
{
"scope": "local",
"projectPath": "/path/to/new/project",
"installPath": "~/.claude/plugins/cache/my-marketplace/my-plugin/1.0.0"
}編集後はClaude Codeを再起動します。開いているセッションに反映させたい場合は、/reload-pluginsで再起動なしにプラグインを反映するの手順で再読み込みしてください。この方法は内部レジストリの直接編集です。将来のアップデートでファイル形式が変わった場合、通用しなくなる可能性がある点は留意しておきます。
派生パターン — マーケットプレイス名の衝突と孤立したprojectPath
issueのコメント欄では、同じ根本原因から派生した挙動もいくつか報告されています。
マーケットプレイス名の衝突: 同名のプラグイン(例: superpowers)がclaude-plugins-officialと別のマーケットプレイスの両方に存在するケースです。/plugin installが意図しないマーケットプレイス側を「既にインストール済み」として拒否します。issueのコメントでは、/plugin install superpowers@superpowers-marketplaceとplugin@marketplaceの完全修飾名で指定してもなおPlugin 'superpowers@claude-plugins-official' is already installedと拒否される例が報告されています。インストール判定が@marketplaceの修飾部分を見ずにプラグイン名だけで一致するため、完全修飾名を指定しても回避になりません。
孤立したprojectPath: プロジェクトAのディレクトリを削除したあとにプロジェクトBを開くケースです。存在しないパスに対して「インストール済み」の表示が残り続けます。Marketplacesタブとインストールコマンドのどちらも、記録されたprojectPathが実際に存在するかを確認していません。
同時セッションでのロック: 同じプラグインを異なるターミナルの2つのセッションで扱うケースです。後から開いたセッション側では、マーケットプレイス追加やインストールが「既にインストール済み」で拒否されます。それでいてInstalledタブには何も表示されません。複数プロジェクトを並行して開く運用ほど、この種の食い違いに遭遇しやすくなります。
早見表 — 症状別の対処
| 症状 | 疑う原因 | 対処 |
|---|---|---|
| 別プロジェクトで「(installed)」と出るがInstalledタブには無い | 疑う原因Marketplaces表示がprojectPathを見ていない | 対処.claude/settings.jsonのenabledPluginsとinstalled_plugins.jsonを手動で追加 |
/plugin installが「already installed」で拒否される | 疑う原因インストールコマンドがprojectPathを見ていない | 対処同上。反映後は/reload-pluginsで再読み込み |
| 削除済みプロジェクトのパスが「インストール済み」のまま残る | 疑う原因孤立したprojectPathエントリ | 対処installed_plugins.jsonから該当エントリを手動削除 |
| 同名プラグインが別マーケットプレイスとして拒否される | 疑う原因マーケットプレイス名の衝突 | 対処installed_plugins.jsonと.claude/settings.jsonのenabledPluginsを手動で揃える(完全修飾名の指定では回避できない) |
このバグとの付き合い方
Claude Codeのchangelogを確認すると、installed_plugins.json自体に触れた修正はこれまでにも入っています。v2.1.128(2026年5月4日)では、削除済みキャッシュディレクトリを指す古いエントリがPATHを汚染する問題を修正しました。v2.1.224(2026年8月7日)では、同じプラグインを複数プロジェクトにインストールした際にインストール記録が壊れる問題を修正しています。
ただし、確認した範囲のchangelog(v2.1.270、2026年9月12日公開分まで)には、issue #14202が指摘する判定ロジックそのものを修正した記載は見当たりません。Marketplaces表示とインストールコマンドがprojectPathを見ていないという不整合です。公式のトラブルシューティングページにも、この挙動を扱う項目はありません。
個人で1プロジェクトだけを触っている場合は影響が出にくい構成です。一方で、同じプラグインを複数のリポジトリで使い分けたいモノレポ運用や、チームでプロジェクトスコープの共有プラグインを使う構成では、このズレに当たる頻度が上がります。
プラグイン構成全体の設計から見直したい場合は、Claude Codeプラグイン完全ガイドでスコープの使い分けを確認できます。--scopeを含む各コマンドのオプションはClaude Code plugin init/installコマンドの全オプションにまとめています。手動編集で触れることになるキャッシュ構造の背景は、Claude Codeプラグインのキャッシュとファイル解決の仕組みで扱っています。
まとめ
プロジェクトスコープでインストールしたプラグインが、別プロジェクトで誤って「インストール済み」と表示される不具合です。原因は、Marketplaces表示とインストールコマンドがprojectPathを見ずにレジストリのキー存在だけで判定していることにあります。Installedタブの一覧表示だけは正しくプロジェクト単位でフィルタされているため、この表示の食い違いから気づけます。
回避策は.claude/settings.jsonのenabledPluginsと~/.claude/plugins/installed_plugins.jsonを、対象プロジェクト向けに手動で揃える方法です。複数のissueコメント投稿者がこの方法で解消したと報告しています。ただし内部ファイルの直接編集であるため、恒久対応ではなく暫定対応として扱うのが実務的です。同じプラグインを複数プロジェクトで使い分ける構成を組む前に、この既知の制約を把握しておくと、原因調査に時間を取られずに済みます。