Skip to content

claude mcp list shows ✘ Failed to connect - cc-switch (Claude Code)

Quick fix

On Windows cc-switch wraps the MCP npx command in cmd /c, breaking the stdio pipe. Edit ~/.claude.json back by hand, or rewrite with claude mcp add.

Error output
claude mcp list 显示 ✘ Failed to connect
English translation

claude mcp list shows ✘ Failed to connect

On Windows, the cc-switch MCP module (claude_mcp.rs) automatically wraps the command: npx you entered into command: cmd with args: ["/c", "npx", ...] when writing config to ~/.claude.json. The wrapper was introduced in an update to silence the Claude Code /doctor warning "Windows requires 'cmd /c' wrapper to execute npx".

The issues plainly contradict each other. #453 asked for cmd /c to be added to silence that /doctor warning, while users in #5132 and #1500 report the wrapper breaking the MCP stdin/stdout pipe, so claude mcp list shows ✘ Failed to connect and browser and editor MCPs cannot connect — while writing command: npx directly with claude mcp add works. A maintainer closed #5132 as a duplicate of #1286, but users report "editing it once in the mcp manager adds the cmd /c wrapper back", so it is not resolved. Separately, #673 confirmed that editing WSL config from Windows also gets wrapped incorrectly (is_wsl_path() only recognises UNC paths starting with \\wsl$); a maintainer confirmed that WSL case fixed, as was the WSL .claude.json path problem in #134.

  1. First confirm the cmd /c wrapper is what broke your MCP: open ~/.claude.json, and if command reads "cmd" with args starting "/c", this is your problem.

    ~/.claude.json(问题状态,Windows 下被自动包装)
    "mcpServers": {
    "chrome-devtools": {
    "type": "stdio",
    "command": "cmd",
    "args": ["/c", "npx", "-y", "chrome-devtools-mcp@latest"]
    }
    }
  2. Workaround: change that MCP entry back to the original command by hand (command to "npx", dropping the "/c" prefix from args), or run claude mcp remove and then claude mcp add to write it directly. The reporter in #5132 confirmed this restores the connection.

    ~/.claude.json(修复后,恢复原始 npx 命令)
    "mcpServers": {
    "chrome-devtools": {
    "type": "stdio",
    "command": "npx",
    "args": ["-y", "chrome-devtools-mcp@latest"]
    }
    }
  3. Mind the trade-off: without cmd /c, Claude Code /doctor may warn again that "Windows requires 'cmd /c' wrapper to execute npx". Some MCPs only work unwrapped (chrome-devtools), and some are the opposite — users in #1500 report needing cmd /c. Choose per the MCP you actually use.

  4. Avoid editing that entry again in the cc-switch MCP management panel — users report the cmd /c wrapper being added back on every save.

  5. If your config is for Claude Code inside WSL (the file at /home/<user>/.claude.json), upgrading cc-switch is enough: a maintainer confirmed the WSL mis-wrapping fixed (#673), as well as the MCP directory following the Claude directory switch (#134).

  6. The native Windows case is still being tracked — follow cc-switch issue #1286.

ToolClaude Code
Version3.8.2 - 3.16.5(受影响版本范围;WSL 场景的误包装已在 #673 之后的新版修复,Windows 原生场景截至 3.16.5 仍未解决)
PlatformsWindowsLinux
Why does cc-switch wrap npx in cmd /c?
It is automatic behaviour, added to silence the Claude Code /doctor warning "Windows requires 'cmd /c' wrapper to execute npx" so MCP servers start correctly on Windows. But for some MCPs, chrome-devtools among them, the wrapper breaks stdio communication instead.
A black console window appears when an MCP starts on Windows. Is that cc-switch?
No. A maintainer confirmed in #5289 that cc-switch only writes config into ~/.claude.json and never starts MCP child processes. Claude Code itself launches the MCP server with cmd /c, and whether the window is hidden depends on Claude Code process launch logic — report it to Claude Code. Child process calls cc-switch makes itself all use CREATE_NO_WINDOW.
Why does an MCP I removed with claude mcp remove come back after switching provider?
A known problem reported in #3082: when switching provider, cc-switch unconditionally writes every enabled MCP in the database back into ~/.claude.json, treating the database as the only source of truth and never seeing the CLI-side deletion. Delete the entry in the cc-switch MCP panel instead. You can also open cc-switch.db under ~/.CC-switch, delete the row from the mcp_servers table, and remove the reference from the provider config (a method contributed by user zouri).
Importing existing MCP says no MCP servers found to import, or an external config change never re-imports. What now?
Check whether the MCP is installed globally, whether you use a custom claude config dir, and whether the config sits in ~/.claude.json rather than ~/.claude/.claude.json (#4645). #1042 also confirmed a code defect: the import function only updates app flags and never merges external changes to url, args and similar, so external edits can never sync into cc-switch. That issue is still open.
I manage WSL Claude Code from cc-switch on Windows and the config still gets wrapped in cmd /c. What now?
That is #673, caused by is_wsl_path() only recognising UNC paths starting with \\wsl$ or \\wsl.localhost. A maintainer replied it is "fixed and will ship in a new release" — upgrade to the latest version.

This is an unofficial community wiki with no affiliation to the cc-switch authors or the project itself. Its content is compiled from the project's public GitHub issues. This site distributes no software.