Windows: ACP-supplied stdio MCP servers fail silently when the command path contains spaces #1129

Summary

On Windows, an MCP server passed in ACP session/new mcpServers doesn't start if its command path contains spaces. The session starts without that server's tools, and the client isn't told. In my case the ACP host was T3 Code, installed at C:\Users\<me>\AppData\Local\Programs\t3code\T3 Code (Beta).exe, so none of its MCP tools ever appeared to the model.

Expected Behavior

The stdio MCP server starts and its tools are available in the session, whatever characters the command path contains. If a server does fail to start, the ACP client is told.

Actual Behavior

createStdioMcpClient calls spawn(command, args, { shell: process.platform === "win32" }). With shell: true, Node joins the command and args without quoting, so cmd.exe runs C:\...\t3code\T3 and exits 1 with "'…\T3' is not recognized as an internal or external command".

The only trace is [acp] mcp <name> (editor): failed … on stderr. The session carries on with no tools from that server, and the ACP client gets no signal.

Steps to reproduce the issue

1. On Windows, put any stdio MCP server executable in a folder whose path contains a space (and optionally parentheses), e.g. C:\Temp\my server (beta)\server.exe. A copy of node.exe running a tiny MCP server script works.
2. Start cmd acp from an ACP client.
3. Send session/new with mcpServers: [{ "name": "test", "command": "C:\\Temp\\my server (beta)\\server.exe", "args": [], "env": [] }].
4. Ask the model to list or use the test server's tools: there are none. stderr shows [acp] mcp test (editor): failed ….
5. Repeat with the same executable in a path without spaces: the tools appear.

Command Code Version

1.88.5

Operating System

Windows

Terminal/IDE

T3 Code (ACP client)

Shell

cmd.exe (spawned by Command Code); host shell PowerShell 7

Session file (optional)

No response

Fix prompt (optional)

In the stdio MCP client (createStdioMcpClient), stop spawning with shell: true on Windows. Spawn the command directly with an args array. If a shell is still needed to resolve .cmd/.bat shims, quote the command and every arg for cmd.exe. Verify it by starting a stdio MCP server whose path contains spaces and parentheses, and checking that its tools appear. Also send ACP clients a per-server connection status, or at least a visible notice, when an editor-supplied MCP server fails to start.

Additional context

• Command Code advertises mcpCapabilities: { http: true }, so hosts can work around this by sending the MCP server over HTTP instead. My T3 Code fork does that now. Stdio servers from other ACP clients are still affected.
• Possibly related: session/load and session/resume on a session that's already open ignore new mcpServers, because attachSession returns the existing session. A client that rotates MCP credentials keeps the old ones. Either apply the new servers or document it.
• Servers configured in ~/.commandcode/mcp.json may hit the same bug if they share this spawn path. I haven't checked.