[BUG] Windows: .claude.json accumulates project keys differing only in case, making the file unparseable and silently hiding MCP servers

Summary

On Windows, ~/.claude.json can end up holding two project keys that differ only in case.
Windows paths are case-insensitive so these address the same directory, but they are written as
two distinct JSON keys. The file then fails strict JSON parsing on duplicate keys, and an MCP
server registered under one casing is invisible to a session reading the other.

What was observed

A user's .claude.json contained both:

C:\Users\<user>\.claude\projects\Project1
C:\Users\<user>\.Claude\projects\Project1

Note .claude vs .Claude.

Consequences, in the order they bit:

1. ConvertFrom-Json (PowerShell) refuses the file outright on duplicate keys, so any tooling

that reads it fails. The session reported: .claude.json won't even parse.

1. An MCP server added with claude mcp add -s local landed under one casing while the running

session read the other. claude mcp add reported success and the server was absent at
runtime, with no warning.

1. Because a malformed .claude.json is not partially recoverable, this can take out every

configured MCP server at once, with no diagnosable cause presented to the user.

Moving the registration to -s user scope avoided the problem, which is consistent with the
project-path key being the trigger.

Why this is likely a Claude Code bug rather than user error

The user had never manually edited .claude.json. Whatever wrote the second casing was Claude
Code itself, presumably from a cwd string captured with different casing in different sessions
(e.g. one launched via a shortcut, another via a shell with a different path spelling).

Expected behaviour

Any of these would fix it:

• normalise project-path keys case-insensitively on Windows on both read and write, so one

directory maps to one key;

• on write, detect an existing key that differs only in case and reuse it rather than adding a

second;

• at minimum, detect the duplicate on read and surface an actionable error naming the two keys,

instead of failing to parse.

Environment

• Claude Code VS Code extension on native Windows, PowerShell 5.1.
• Exact Claude Code version was not captured at the time. I am reporting this second-hand from

the affected user's session output, including the two path strings and the parse failure text
quoted above; I did not inspect the file directly, so I cannot confirm anything beyond what
that session reported.