[BUG] Project-scoped plugin installs (--scope project) load in CLI sessions but are silently ignored by the VS Code extension

Having the same issue. Spent hours over the past couple of days trying to get this working. My org's entire plugin distribution model relies on a shared internal plugin marketplace + project-scoped plugins in repos. Any ETA on a fix for this?

I did some extensive testing yesterday on this and it looks like the issue #74912 hit the nail on the head. It's a case-sensitivity check that breaks the plugin cache resolution. Here's what I found:

1. This was working in 2.1.179
2. This broke in 2.1.181 (Note: There was not a published 2.1.180)
3. A quick workaround is to manually edit ~/.claude/plugins/installed_plugins.json and ~/.claude/plugins/known_marketplaces.json and replace upper case drive letters with lower case drive letters (e.g. replace C: with c:) and restart VSCode. Then run /reload-skills to see that all plugins are loaded. Note: This will work for a while, but eventually it will override the drive letters back to upper case as it updates plugins and marketplaces.

Also, as a quick work around, downgrading to 2.1.179 for both Claude CLI and VSCode extension works:

Downgrade Claude CLI:

$ claude install 2.1.179

Downgrade Claude VSCode Extension:

1. Open up Extensions and find the Claude Code for VSCode extension.
2. Click Uninstall > Install Specific Version....
3. Select 2.1.179 out of the list
4. Restart VSCode.

<img width="634" height="284" alt="Image" src="https://github.com/user-attachments/assets/df33c366-2a4b-47e0-ad7c-f6b898a3f32f" />

Same failure mode on macOS with the desktop app, which I think means the drive-letter case-sensitivity theory from #74912 can't be the whole story.

Environment

• Claude desktop app 1.24012.9 (Electron 42.7.0, Node 24.18.0), macOS arm64
• CLI on the same machine, launched from the same directory: works correctly (control case)
• Windows desktop app: also works correctly (control case)

Setup — one project with plugins enabled at project level.

~/.claude/settings.json (user scope):

{ "enabledPlugins": { "mattpocock-skills@mattpocock": true } }

<project>/.claude/settings.json:

{
  "enabledPlugins": { "marketing-skills@marketingskills": true },
  "permissions": { "allow": ["Bash(lftp:*)"] }
}

<project>/.claude/settings.local.json:

{
  "permissions": { "allow": ["Bash(git commit *)", "Bash(git push *)"] },
  "enabledPlugins": { "laravel@laravel": true, "impeccable@impeccable": true }
}

~/.claude/plugins/installed_plugins.json holds the matching install records with the correct scope (project for marketing-skills, local for laravel and impeccable) and the correct projectPath.

Actual

The desktop app's plugin menu (+ → Plugin) lists only mattpocock-skills — the single user-scoped plugin — and shows an identical list in every project I open. Every project-scoped and local-scoped plugin is silently absent, with no error or warning. The CLI launched from the same directory registers all four.

Same "it reads the file, just not that key" evidence as the original report: the permissions entries from those two project files are applied correctly by the desktop app. Only enabledPlugins is dropped.

Two details that may help narrow it down

• There is no path mismatch of any kind in this case. pwd and pwd -P in the project directory return a string identical to the stored projectPath — no symlink or firmlink indirection, no case difference, and no drive letters on macOS. So whatever #74912 describes for Windows, there appears to be a second failure path that triggers with exactly-matching paths.
• It affects scope: "project" and scope: "local" entries equally.

installed_plugins.json parses as valid JSON and the plugin payloads are correctly present under ~/.claude/plugins/cache/, so this is not a cache-miss or a corrupted-config situation on my side.

Confirming this on a different plugin, from a non-official marketplace, and on a newer extension build. Same behavior, so it is not specific to superpowers or to the official marketplace.

Environment

• Claude Code CLI: v2.1.185 (Windows 11)
• VS Code extension: anthropic.claude-code v2.1.220-win32-x64 (newer than the v2.1.201 in the original report — still reproduces)
• VS Code: 1.130.0
• Plugin: a third-party open-source plugin installed from a self-hosted GitHub marketplace (not claude-plugins-official)
• Reproduced independently on two separate machines (both Windows 11).

Additional data point: the plugin UI itself diverges

The original report covers skill registration. The /plugin surface diverges too, and I think it points at the mechanism.

~/.claude/plugins/installed_plugins.json contains three "scope": "project" records for the same plugin, each with a different projectPath (accumulated over time as it was installed into several workspaces):

"<plugin>@<marketplace>": [
  { "scope": "project", "projectPath": "C:\\path\\to\\project-a", ... },
  { "scope": "project", "projectPath": "C:\\path\\to\\project-b", ... },
  { "scope": "project", "projectPath": "C:\\path\\to\\project-c", ... }
]

Opening the same workspace (project-c) in both surfaces:

| | CLI (/plugin) | VS Code (Manage Plugins) |
|---|---|---|
| Entries shown | 1, under a Project group | 3 identical rows, no scope grouping |
| State | ✓ enabled | all toggles off |
| Stale paths | not shown | shown |

Two of those three projectPath values point at directories that no longer exist on disk, and the extension lists them anyway. So the extension does not appear to filter installed_plugins.json records against the current workspace path at all — it flattens the array and renders every record, none of which end up enabled. The CLI, by contrast, resolves the record matching the current project and marks it enabled.

Skill-level symptom in the same workspace

The workspace also has fallback slash commands in .claude/commands/ that wrap the plugin's skills, which makes the difference easy to see side by side:

• CLI — typing /<name> lists both: the project-scoped fallback command and the plugin skill (rendered with the plugin-name prefix and the description from its SKILL.md).
• VS Code — only the fallback commands appear. No plugin-prefixed entries, no SKILL.md descriptions.

Control group, consistent with the original report: user-level skills in ~/.claude/skills/ and built-in skills register normally in the extension in the same session. Only plugin-provided skills are missing.

Possibly related

• #70655 (plugin management: duplicate entries / silent load failures) — the "3 identical rows" above looks like the duplicate-entry symptom described there.
• #75855 (Windows drive-letter case not canonicalized in project keys) — worth noting the extension reports the workspace cwd with a lowercase drive letter (c:\...) while installed_plugins.json stores it uppercase (C:\...). I could not confirm whether the comparison is case-sensitive, but if it is, it would explain why zero records match in the extension while the CLI resolves one.