[BUG] Local-scoped plugin fails to load on Windows with `plugin-cache-miss` due to case-sensitive `projectPath` comparison

I spent some time testing this yesterday to try to find exactly which version this broke in and confirm if this is actually a case-sensitivity issue and looks like that is exactly it. I started downgrading versions until I found one where it worked and it turns out this was working fine in 2.1.179 and broke in 2.1.181 (Note: I didn't see a published version for 2.1.180). The issue #74612 is related to this so a fix for this should fix that as well.

A quick and easy way to reproduce it is to run /reload-plugins from the VSCode extension and observe the VSCode output logs for the Claude Code extension. You will see things like the following in a broken version:

2026-07-08 00:05:46.842 [info] From claude: 2026-07-08T04:05:46.842Z [DEBUG] Plugin loading errors: Plugin "claude-md-management" not cached at C:\Users\dflor\.claude\plugins\marketplaces\claude-plugins-official — run /plugins to refresh, Plugin "dotnet" not cached at C:\Users\dflor\.claude\plugins\marketplaces\dotnet-agent-skills — run /plugins to refresh, Plugin "dotnet11" not cached at C:\Users\dflor\.claude\plugins\marketplaces\dotnet-agent-skills — run /plugins to refresh, Plugin "dotnet-msbuild" not cached at C:\Users\dflor\.claude\plugins\marketplaces\dotnet-agent-skills — run /plugins to refresh, Plugin "dotnet-aspnetcore" not cached at C:\Users\dflor\.claude\plugins\marketplaces\dotnet-agent-skills — run /plugins to refresh, Plugin "dotnet-nuget" not cached at C:\Users\dflor\.claude\plugins\marketplaces\dotnet-agent-skills — run /plugins to refresh, Plugin "dotnet-test" not cached at C:\Users\dflor\.claude\plugins\marketplaces\dotnet-agent-skills — run /plugins to refresh, Plugin "dotnet-upgrade" not cached at C:\Users\dflor\.claude\plugins\marketplaces\dotnet-agent-skills — run /plugins to refresh, Plugin "skill-creator" not cached at C:\Users\dflor\.claude\plugins\marketplaces\claude-plugins-official — run /plugins to refresh, Plugin "superpowers" is enabled in project settings but isn't installed — run `claude plugin install superpowers@claude-plugins-official --scope project`
2026-07-08T04:05:46.842Z [DEBUG] getPluginSkills: Processing 0 enabled plugins

The test I did to confirm that it was indeed a case-sensitivity issue is as follows:

1. Open up VSCode and run /reload-skills to check the skill count in the "broken" state.
2. Shutdown all instances of VSCode and Claude CLI.
3. Edit ~/.claude/plugins/installed_plugins.json and ~/.claude/plugins/known_marketplaces.json to replace upper case drive letters with lower case drive letters (e.g. C: -> c:).
4. Re-open VSCode and start a chat session.
5. Run /reload-skills and observe the skill count.

If it worked, you should now see more skills coming from the plugins you 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.

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.

A few additional data points that may help pin down the fix (from diagnosis session using Opus):

1. The exact VS Code code path that lowercases the drive letter. The extension host's lowercase-c: working directory isn't incidental — it comes from uriToFsPath() in VS Code's src/vs/base/common/uri.ts (also shipped as the vscode-uri npm package). The URI.fsPath getter calls uriToFsPath(this, /* keepDriveLetterCasing */ false), and with that flag false it executes:

value = uri.path[1].toLowerCase() + uri.path.substr(2);   // drive letter forced lowercase

This is intentional, long-standing VS Code behavior (the keepDriveLetterCasing opt-out exists precisely because normalization is the default). So the fix has to live on the Claude Code side — the extension will always hand over a lowercase drive letter and that won't change.

2. The CLI writes uppercase C: regardless of the shell's casing. I confirmed the uppercase projectPath is not inherited from the installing shell: claude plugin install --scope project recorded C:\... even when run from a Git Bash shell whose pwd was lowercase /c/.... Verified across 4 independent installs (interactive CLI and via tooling). So this reproduces for any user regardless of how they install — it's not a quirk of one shell setup.

3. It can manifest silently, not just as plugin-cache-miss. In my case the project-scoped plugins' skills/commands simply didn't appear in the VS Code session at all, with no error or log line — while user-scoped plugins loaded fine in the same session. Same underlying casing mismatch, but worth noting the symptom isn't always the plugin-cache-miss message; sometimes it's a silent absence.

4. A more robust workaround for people who use both the CLI and VS Code. Editing installed_plugins.json to lowercase the projectPath in place fixes VS Code but then breaks the CLI (which matches on uppercase) — so you ping-pong between the two. Since each plugin's value is an array of install records, you can instead keep both casings — add a duplicate record with the opposite drive-letter casing (one C:\..., one c:\..., both pointing at the same cache installPath). Then whichever casing a client presents, one entry matches, and both environments work simultaneously. Still fragile (a later install/enable/update may rewrite or dedupe the entries), but it survives switching between CLI and VS Code.

Additional evidence for the casing mismatch, beyond installed_plugins.json:

• ~/.claude/sessions/*.json (VS Code session) — "cwd": "c:\\...", "entrypoint": "claude-vscode" (lowercase)
• ~/.claude/ide/*.lock — "workspaceFolders": ["c:\\..."] (lowercase)

Same CLI binary/version in both cases (entrypoint: claude-vscode runs the same binary) — only the drive-letter casing of the project path differs.

Confirming this same root cause (case-sensitive comparison of a case-insensitive Windows path) also breaks ~/.claude.json project-scoped config, not just plugin loading — so this isn't area:plugins-specific, it's a general Windows path-handling issue in Claude Code.

Environment: Claude Code 2.1.232, Windows 11, project opened both via CLI (external PowerShell terminal) and via the VSCode extension.

What I found: opening the same project through the CLI and through the VSCode extension creates two separate entries under projects in ~/.claude.json that differ only in drive-letter case:

"D:/my/project/folder": { ... }   // created by CLI
"d:/my/project/folder": { ... }   // created by VSCode extension

The CLI-created entry accumulates real session state (lastCost, lastDuration, lastSessionId, hasTrustDialogAccepted: true, etc.) while the VSCode-created entry stays mostly at defaults (hasTrustDialogAccepted: false) — so on Windows, trust approval and MCP config effectively have to be redone per-frontend.

I dug into why the casing differs, since it seemed worth nailing down for a fix:

• Native Windows shells consistently report an uppercase drive letter for cwd, regardless of what case you typed in cd. Verified empirically:

``
PS> Set-Location d:\some\path
PS> node -e "console.log(process.cwd())"
D:\some\path
`
(Same result from Git Bash's spawned Node process — process.cwd() / libuv's uv_cwd()` returns uppercase.)

• The VSCode extension instead normalizes the workspace path to a lowercase drive letter before using it (this matches vscode-uri's long-standing Windows path normalization behavior).

So the mismatch isn't caused by user habit (typing cd D:\... vs cd d:\...) — it's a structural disagreement between how the CLI derives its cwd (raw OS-reported, uppercase) and how the VSCode extension derives its workspace path (normalized, lowercase). No amount of consistent typing on the user's side fixes it; the normalization has to happen on Claude Code's side, e.g. case-folding the drive letter (either direction, just needs to be consistent) before using a Windows path as a projects key — same fix this issue already proposes for installed_plugins.json / projectPath comparison.

Also worth linking as prior reports of the same underlying bug, all Windows-only path-casing issues, mostly closed as stale/duplicate without a fix landing: #18122, #45195, #46586, #19910, #25756, #56642.