Windows: project entries in ~/.claude.json keyed case-sensitively - CLI and VSCode sessions silently see different config for the same folder

Environment: Windows 11 Pro, Claude Code CLI + VSCode extension, same user account.

Summary

~/.claude.json stores per-project state in the projects dictionary, keyed by the session's working-directory path as a raw string, compared byte-exactly. Windows paths are case-insensitive, so the same folder legitimately arrives with different casing depending on what launched the session — and each casing becomes (or looks up) a different key. Nothing canonicalizes the path on write or read.

This produces two distinct symptoms with one root cause:

Symptom A — drive-letter divergence (systematic, client-determined). Shells report C:\Users\... (uppercase drive letter); VSCode-spawned sessions report c:\Users\... (VSCode lowercases drive letters internally). A project entry written from a CLI session is keyed C:/... and is invisible to every VSCode session in the same folder, and vice versa. This includes CLI sessions launched from VSCode's integrated terminal (they inherit VSCode's lowercase cwd).

Symptom B — path-body divergence (incidental, typing-determined). PowerShell preserves the casing the user types for path segments (cd ...\documents\code repos vs tab-completed ...\Documents\Code Repos). Both spellings resolve to the same folder on disk but become separate keys. My config currently contains this live pair, both with capital drive letters:

"C:/Users/francis.MYVIRTUALZEN/documents/code repos/Adrianne Buckley Photography"
"C:/Users/francis.MYVIRTUALZEN/Documents/Code Repos/Adrianne Buckley Photography"

Impact

• MCP servers registered at local scope from the CLI never load in VSCode sessions for the same project (and vice versa). The failure is completely silent — no error, no warning, the servers just aren't there. (This cost me weeks of intermittent "why is my MCP server missing" confusion; the answer depended on which client I happened to be in.)
• Once two spellings of a folder have each been written, the file holds case-variant duplicate entries — permanently forked permissions, trust decisions, and state per client/spelling.
• The duplicate case-variant keys also break strict JSON consumers (PowerShell's ConvertFrom-Json refuses the whole file without -AsHashTable).
• Diagnosis is misleading: claude mcp list run from a terminal resolves the CLI's spelling and reports the server Connected, while the VSCode session sitting in the same folder can't see it.

Steps to reproduce (Symptom A)

1. In PowerShell, cd to any project and run claude mcp add <server> ... --scope local.
2. Open the same folder in VSCode and start a Claude Code session.
3. The server is absent. Inspect ~/.claude.json: the entry is keyed C:/...; the VSCode session looked up c:/....

For Symptom B: cd to the same project with a hand-typed lowercase segment (e.g. cd C:\users\<you>\documents\<project>), take any action that writes project state, and observe a second entry appear alongside the tab-completed spelling.

Expected behavior

Canonicalize paths before using them as project keys on case-insensitive filesystems — resolve the true on-disk casing via the filesystem (normalizing only the drive letter would fix Symptom A but not B) — and migrate/merge existing case-variant duplicate entries on load.