[BUG] MCP Connectors failing on Claude Desktop

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/35399
2. https://github.com/anthropics/claude-code/issues/57559
3. https://github.com/anthropics/claude-code/issues/50559

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Closed but possibly useful for others hitting this. Disclaimer up front: what follows is my best-effort hypothesis based on log files, observable Claude Desktop behavior, public MSIX/npm documentation, and related closed issues. I don't have access to Claude Desktop's source, so the root cause is inferred, not confirmed.

TL;DR (hypothesis): For MCP servers spawned via npx -y <pkg>, the MSIX-packaged Claude Desktop on Windows appears to rewrite %APPDATA% for child processes from C:\Users\<u>\AppData\Roaming\ to C:\Users\<u>\AppData\Local\AnthropicClaude\app-<version>\ (this is documented MSIX container behavior for packaged apps that don't opt out via the package manifest). npm's _npx cache lives under %APPDATA%\npm-cache\_npx, so on every Claude restart npx doesn't see its previously-cached extracted package and re-downloads from the registry. Cold start ends up at ~85s on a healthy machine; the ~60s initialize timeout fires; the server is killed ~25s before it would have been ready. Repeats every restart, never converges.

Log signature (%APPDATA%\Claude\logs\mcp-server-<name>.log, timestamps abbreviated):

T+0.0s    Server started and connected successfully    ← this is cmd.exe, not the MCP server
T+0.7s    Message from client: {"method":"initialize"...}
T+60.0s   notifications/cancelled "MCP error -32001: Request timed out"
T+70.8s   <server name> running on stdio               ← server ready, ~10s too late
T+85s     Server transport closed

If you see running on stdio appearing in the log after the timeout fires, you're likely hitting this. The server isn't broken — it just can't beat the clock.

Workaround that worked for me: skip npx at runtime. Install the package globally once and write a direct node <bin path> to claude_desktop_config.json:

{
  "command": "C:\\Program Files\\nodejs\\node.exe",
  "args": ["C:\\Users\\<u>\\AppData\\Roaming\\npm\\node_modules\\@modelcontextprotocol\\server-github\\dist\\index.js"]
}

(after a one-time npm install -g @modelcontextprotocol/server-github)

Spawn cost drops from ~85s cold to ~300ms — and stays that fast on every restart, because no npx registry lookup happens. Reproduces across @modelcontextprotocol/server-github, @notionhq/notion-mcp-server, @roychri/mcp-server-asana@beta, figma-developer-mcp, mcp-remote — not specific to any one server.

On macOS the same npx -y works in ~3–8s. No MSIX, no %APPDATA% rewrite, native execve() (no cmd.exe wrapper), no Defender real-time scanning, faster small-file ops on APFS — fits under the 60s budget. The Windows-specific failure is what makes this look like an MCP-layer bug when it's likely a packaging/env one.

Suggestions for upstream (again, educated guesses based on the above):

1. Look at the MSIX %APPDATA% rewrite. Whatever it's meant to serve, it appears to silently break every Node tool that caches under %APPDATA% (npm, yarn, pnpm, vite, …). Worth confirming and either documenting or addressing.
2. Update sample MCP configs in the docs to use globally-installed packages with direct node paths on Windows.
3. The initialize timeout in Claude Desktop appears unconfigurable at runtime. MCP_TIMEOUT env only affects the claude mcp list CLI health check (per #57559), not the desktop spawn.

Caveat: I can't verify the MSIX env rewrite hypothesis from inside Claude Desktop. Confirmation would require either reproducing in a clean MSIX environment with subprocess env logging, or someone on the Anthropic team checking the actual sandboxing setup. The behavior I'm describing is consistent with everything I've observed, but I could be wrong about the mechanism.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.