[BUG] .mcp.json at a Windows drive root is never discovered — absent from claude mcp list, no warning

Summary

When a Claude Code session's working directory is a Windows drive root (e.g. D:\), a .mcp.json file at that root is never discovered. The servers it defines do not load, do not appear in claude mcp list, and no warning or error is shown. Moving the identical file one directory down makes it work immediately.

The failure is in discovery, not in the project-scope approval gate — see the evidence section below.

Reproduction

1. Create D:\.mcp.json with any stdio server:

{
  "mcpServers": {
    "demo": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "D:\\"]
    }
  }
}

1. Start Claude Code with the working directory set to D:\.
2. Run claude mcp list (or /mcp).

Actual: demo is absent from the output entirely. No prompt to approve the project-scope server at startup, no warning, no error.

Expected: the server is discovered and either connects or is offered for approval, exactly as it would be from any subdirectory.

1. Copy the same file to D:\somefolder\.mcp.json, start a session with cwd D:\somefolder, run claude mcp list again — the server is discovered and connects.

Evidence that this is discovery, not the approval gate

Same machine, same user, same session config, two runs of claude mcp list differing only in cwd:

cwd = D:\subdir   (.mcp.json in that dir)     -> server listed, Connected
cwd = D:\         (D:\.mcp.json, same shape)  -> server not listed at all

Additional state from ~/.claude.json for the D:/ project entry:

• hasTrustDialogAccepted: true
• enabledMcpjsonServers: []
• disabledMcpjsonServers: []

Both approval lists are empty, so the server is neither enabled nor disabled. If this were the normal project-scope approval flow, the server would still appear in claude mcp list in a pending/disabled state and would have triggered an approval prompt at startup. It is absent entirely, which indicates the file is never read.

The .mcp.json itself is valid: parses cleanly, no BOM (first bytes 7B 0D 0A 20), correct mcpServers shape with type: stdio.

Environment

• Claude Code 2.1.226 (native install, latest channel)
• Windows 11 Pro, build 26200
• Drive: local physical drive D:\ (not a network/mapped drive)
• VS Code extension connected

Relationship to prior reports

This was previously reported in #43499 (Claude Code 2.1.91, same symptom, same workaround). That issue was automatically closed by the duplicate-detection bot as a duplicate of #41465 and then locked, so it can no longer be commented on.

#41465 is a different bug — "Edit/Write tools fail with EPERM on Windows drive root paths", about mkdir 'D:\' failing during file writes. It shares the phrase "Windows drive root" but is unrelated to config discovery, and is itself closed as stale. No maintainer ever reviewed either issue; every comment on both threads is from the automation.

One difference worth noting from #43499: that report used a drive letter mapped over SMB to a NAS, which left open the possibility that a network filesystem was the cause. This reproduction is on a plain local drive, which rules that out and points at path handling for root directories.