Windows: MCP stdio server startup fails when an allowed-directory path contains a space (filesystem server via npx)

**Environment:** Claude Desktop on Windows 11 (reported against a fresh install, Claude 1.32885.1). `mcpServers.filesystem` configured via `npx -y @modelcontextprotocol/server-filesystem `.

**Symptom:** the server disconnects immediately at startup ("MCP server filesystem disconnected") whenever one of the configured allowed-directory paths contains a space, e.g. `C:\No_Backkup\NS\Claude Code Group`. A directory with no space in the same config entry works fine. Confirmed on a completely fresh install (fresh `claude_desktop_config.json`, no prior state) — this rules out a stale cached `npx` package version, which was the original suspected cause.

Original report and reproduction: modelcontextprotocol/servers#447 (comments from 2026-08-16 through 2026-08-19).

**What I ruled out, with evidence:**

I initially assumed this was a Windows argv-quoting bug in how a client spawns `npx` (which resolves to `npx.cmd` on Windows — `.cmd` files can't be spawned with `shell:false` at all, `child_process.spawn` throws `EINVAL`). Testing that hypothesis directly:

1. `child_process.spawn(cmdPath, args, { shell: true })` — **does** split a space-containing path into multiple argv tokens (`"...\Claude Code Group"` arrives as three separate arguments: `...\Claude`, `Code`, `Group`). This matches Node's own deprecation warning (DEP0190: "arguments are not escaped, only concatenated" under `shell: true`). Looked like a strong candidate.
2. But the official `@modelcontextprotocol/sdk`'s `StdioClientTransport` doesn't use raw `shell:true` — it spawns via `cross-spawn` with `shell: false`. Tested that exact call directly: it correctly quotes the space-containing argument and the child receives it as a single, intact argv element.
3. Tested the **full real chain** end-to-end — `cross-spawn` → `npx -y @modelcontextprotocol/server-filesystem` → the actual filesystem server package, against a real on-disk directory named `...\Claude Code Group\`. It started cleanly with no warnings and no error ("Secure MCP Filesystem Server running on stdio").

So the code in `modelcontextprotocol/servers` (its `path-utils.ts` normalization is also fine on inspection — it never touches spaces) and the core spawn mechanism in the published SDK are both clean. Whatever is corrupting or rejecting the space-containing path has to be happening somewhere in Desktop's own config-to-spawn pipeline — before the args ever reach a `StdioClientTransport`-equivalent call, or in how Desktop itself constructs/passes that call — not in the MCP server or SDK code that's publicly inspectable.

**Possible related precedent:** #832 documents Desktop building its own allow-listed child environment for spawned local MCP servers (missing `PATHEXT`) rather than behaving identically to the SDK's own `getDefaultEnvironment()` — i.e. Desktop's actual spawn path isn't a verbatim pass-through of the public SDK code, so there's room for a divergence like this one to live entirely on Desktop's side.

**What would help narrow this down further:** I don't have visibility into Desktop's own (closed-source) process-spawning or config-parsing code, so I can't point at a specific line. A repro from someone who does have that visibility, or Desktop-side logging of the literal argv it hands to the child process, would settle whether this is an argv-construction issue, a config-parsing/sanitization step, or something else entirely.

**Suggested labels:** `bug`, `local-mcp-server`

Made with Claude Code.