[BUG] Windows: case-sensitive `.claude.json` project-key lookup silently drops MCP servers across CLI/VS Code — recurring bug, repeatedly auto-closed unfixed

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

On Windows, per-project config in ~/.claude.json is keyed by the working-directory path string, and the lookup is case-sensitive even though Windows paths are not. The drive-letter case differs by launch surface:

• VS Code-hosted sessions canonicalise the drive letter to lowercase (c:/...)
• CLI / desktop sessions (PowerShell) write/look up uppercase (C:/...)

So a project ends up with two entries differing only by drive-letter case, and mcpServers lives on only one of them. The MCP servers silently don't load on whichever surface lands on the other casing — /mcp shows "No MCP servers configured", no error. Worse, editing the key to the casing one client wants causes the other client to re-add its own casing on next launch, so the two entries drift and project-level MCP can't work across CLI and VS Code simultaneously.

The silence is the real cost: with no error, it sends you checking org/feature-gate policy and the MCP server itself before the config key — which is exactly what the prior reporters (and we) did.

What Should Happen?

Claude Code should normalise drive-letter case when both writing and looking up project keys in ~/.claude.json on Windows (canonical lowercase aligns with what the VS Code extension forces), consistently across the CLI, desktop app, and VS Code extension — and no client should re-add an opposite-case duplicate entry on subsequent launches. A migration that collapses existing duplicate-cased entries would also help. Alternatively, warn on near-duplicate project keys differing only by case.

Error Messages/Logs

terminal $PWD:                         C:\Users\...\<repo>   (uppercase C:)
VS Code session cwd:                   c:\Users\...\<repo>   (lowercase c:)
.claude.json key written by CLI:       "C:/Users/.../<repo>" (uppercase)
VS Code subprocess lookup key:         "c:/Users/.../<repo>" — does NOT match → no mcpServers loaded

Steps to Reproduce

1. Windows. From a project dir in a terminal, add an MCP server via CLI (claude mcp add ...). The CLI writes a project key like "C:/Projects/<repo>" (uppercase) with the mcpServers block.
2. Open the same project in VS Code and start a Claude Code session. The extension resolves to "c:/Projects/<repo>" (lowercase) — a different key with no mcpServers.
3. Run /mcp in the VS Code session → "No MCP servers configured" (works fine in the terminal session).
4. Manually lowercase the key to fix VS Code → the CLI/desktop re-adds the uppercase entry on next launch, duplicating it; the surfaces now permanently disagree.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.173 — both the Claude Code CLI and the VS Code extension were on 2.1.173 at the time of reproduction. The VS Code extension has since auto-updated to 2.1.174 (not yet retested on that build); CLI remains 2.1.173. For contrast, the prior reports below were all on 2.1.96.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

Prior reports (all auto-closed, none fixed)

This is the part worth a human's attention: the dedup + staleness automation has buried a confirmed, current-version bug.

• #45195 — same bug; closed "as not planned" by the staleness bot for inactivity (with a 👎 on the closing comment).
• #46586 — same bug; closed "as duplicate of #45195", then locked — i.e. deduped into an issue that was itself stale-closed unfixed.
• #18122 — duplicate project entries from d:/ vs D:/ causing MCP servers not to load (same root cause).
• #39413 — project-memory path case mismatch between system prompt and disk (same case-sensitivity family).

Net: reported independently ~4× (on 2.1.96) and still reproduces on 2.1.173 — roughly 77 patch releases later — with every instance auto-closed without a fix. Request: triage/reopen and fix the path-key normalisation, rather than auto-closing this as a duplicate of an already-stale-closed issue.

Workaround (drifts, not a fix): duplicate the project entry in ~/.claude.json under both C:/... and c:/... keys, each carrying the mcpServers block, so it resolves regardless of launch surface. These drift out of sync when servers are updated via one client vs another.