Windows: v1.0.66 fails to start stdio MCP servers when command is a .bat/.cmd with args (regression from 1.0.65)

[chronofanz]

Summary

On Windows, v1.0.66 fails to start any stdio MCP server whose command is a .bat/.cmd file and is registered with one or more args. The child process dies immediately with cmd.exe's The syntax of the command is incorrect. and the client reports connection closed: initialize response. The exact same servers worked in v1.0.65.

This looks like a regression in how the Windows .bat/.cmd spawn path builds/quotes the command line (consistent with the post‑CVE‑2024‑27980 Node hardening for batch files).

Environment

• Copilot CLI: 1.0.66-1 (broken) — worked on 1.0.65
• OS: Windows 11 (10.0.26200), x64
• Install: WinGet (GitHub.Copilot)
• Bundled Node: v24.16.0

What fails vs. what works

Given these MCP registrations:

command	args	Result on 1.0.66
foo.bat	["serve"]	❌ fails: The syntax of the command is incorrect.
foo.bat	[] (no args)	✅ works
python.exe (a real .exe)	["-m","foo","serve"]	✅ works
http server	n/a	✅ works

So the failure is specific to .bat/.cmd command + non-empty args. Removing the argument (or pointing command at a real .exe) avoids it.

Logs

[ERROR] Starting MCP client for dashpilot with command: d:\LRPBot\dashpilot.bat and args: serve
[ERROR] [mcp server dashpilot stderr] The syntax of the command is incorrect.
[ERROR] Failed to start MCP client for dashpilot: Error: failed to initialize MCP client: connection closed: initialize response

In the same session, every .bat … serve server failed identically (5 of them), while one .bat registered with empty args and all http servers started fine. On 1.0.65, all of the same .bat … serve servers started normally.

Minimal reproduction

1. Create C:\tmp\echo.bat:

   @echo off
   echo got arg: %~1 1>&2

2. Register it with an argument:

   copilot mcp add repro -- "C:\tmp\echo.bat" serve
   

3. Launch copilot → the repro server fails to start with The syntax of the command is incorrect.
4. Re-register without the argument and the spawn no longer errors:

   copilot mcp remove repro
   copilot mcp add repro -- "C:\tmp\echo.bat"
   

(For a server that actually completes MCP initialization, wrap any stdio MCP server in a .bat and register it -- "wrapper.bat" serve vs -- "wrapper.bat".)

Expected

A .bat/.cmd MCP command with args should be spawned with a correctly quoted command line (as it was in 1.0.65), so the server initializes normally.

Workaround

Register the .bat with no args (have the batch file default to its serve subcommand), or point command directly at the underlying .exe (e.g. the venv python.exe) with the args.

[chronofanz]

Additional root-cause analysis (binary diff of 1.0.65 vs 1.0.66)

Since the implementation isn't open source, I compared the two shipped Windows binaries that WinGet leaves on disk after an update — copilot.exe (1.0.66) and copilot.exe.old (1.0.65) — to localize the regression.

Node runtime is ruled out. The embedded Node core normalizeSpawnArguments region (lib/internal/child_process.js) — the shell:true branch that builds the Windows command line — is byte-identical between the two versions:

if (RegExpPrototypeExec(/^(?:.*\\)?cmd(?:\.exe)?$/i, file) !== null) {
  args = ['/d', '/s', '/c', `"${command}"`];
  windowsVerbatimArguments = true;
}

A block-level diff shows the only meaningful change (~+2 MB) is in the application bundle, not the Node runtime. So this is an app-level change to how the stdio MCP .bat/.cmd server is spawned, introduced in 1.0.66.

Why this is almost certainly a quoting regression. The failure surfaces as cmd.exe's The syntax of the command is incorrect. (not Node's EINVAL), which means the .bat is being run through cmd /d /s /c "<command>". Node already wraps the entire command in a single quote pair. The classic way to produce that exact cmd error is to pre-quote the program path before handing it to a shell:true spawn, yielding a doubled outer quote:

cmd /d /s /c ""C:\path\foo.bat" serve"

which cmd.exe mis-parses. This lines up with the 1.0.65 changelog entry "Keep Windows paths intact when adding stdio MCP servers" — that Windows-path quoting work appears to have overshot in 1.0.66 into the spawn path that already quotes via cmd /c. It also explains why the no-argument case still works: with nothing after the path, the doubled-quote parse doesn't break.

Suggested fix direction: for a .bat/.cmd MCP command on Windows, either

1. don't pre-quote the program path when passing it to a shell:true spawn (let Node do the single-level /d /s /c "…" wrap), or
2. spawn with shell:false passing command + args as an array — modern Node (≥ the CVE-2024-27980 fix) safely escapes .bat/.cmd arguments itself.

Workaround for affected users today: register the .bat with no args (have it default to its serve subcommand), or point command directly at the underlying .exe (e.g. the venv python.exe) with the args — both avoid the broken quoting path.