[Bug]: Windows: execFileSync fails for command-based clients (claude-code/gemini-cli/codex) — .cmd shims not resolved

[chirag127]

What actually happened?

On Windows, smithery mcp install <server> --client claude-code (and the same for gemini-cli / codex) fails with:

Command 'claude' not found. Make sure claude is installed and on your PATH

…even when claude is installed and callable from any shell. Reproducible with @anthropic-ai/claude-code installed globally via npm i -g:

> where.exe claude
C:\Users\<user>\AppData\Roaming\npm\claude
C:\Users\<user>\AppData\Roaming\npm\claude.cmd

Both files exist. Only .cmd is executable on Windows — the extension-less shim is a POSIX shell script that Windows cannot execute directly.

Root cause

src/lib/client-config-io.ts → runConfigCommand() (~line 380) calls:

const output = execFileSync(command, args)

Per Node.js docs (child_process.execFileSync): on Windows this does not invoke a shell, so .cmd / .bat / .ps1 shims are not resolved from PATHEXT — only .exe is auto-tried. Since @anthropic-ai/claude-code (and @google/gemini-cli, @openai/codex) ship a .cmd shim rather than a .exe, the spawn returns ENOENT and the CLI emits the misleading "Command not found" branch.

The vscode and vscode-insiders client definitions already work around this by branching:

// src/config/clients.ts
command: process.platform === "win32" ? "code.cmd" : "code",

The command-based clients missing this branch:

Client key	install.command on Windows	Real binary
claude-code	claude	claude.cmd
gemini-cli	gemini	gemini.cmd
codex	codex	codex.cmd

Expected behavior

Any one of:

1. Same fix as vscode — append .cmd in each command field when process.platform === "win32".
2. Central fix in runConfigCommand — on Windows, if execFileSync(command) throws ENOENT, retry with command + ".cmd". Cleaner: pass { shell: true } to execFileSync, which respects PATHEXT — but that opens quoting concerns for args.
3. spawn/execFile on Windows with an explicit PATHEXT walk. Slightly more code, no shell-quoting worry.

Option 1 keeps the change local and mirrors the existing vscode pattern — probably the smallest surface-area fix.

Steps to reproduce

1. Windows 10/11, npm i -g @anthropic-ai/claude-code smithery
2. where.exe claude → shows claude and claude.cmd
3. smithery mcp install exa --client claude-code
4. Observe: Command 'claude' not found… despite claude being on PATH.

Same reproduction with --client gemini-cli (after installing @google/gemini-cli) and --client codex.

Related

• [Bug]: smithery mcp add with --client claude-code gives misleading error message #781 — user hit this and misdiagnosed as an invalid --client value; the actual claude-code key is valid, the failure is one layer deeper. Closing this bug would resolve [Bug]: smithery mcp add with --client claude-code gives misleading error message #781's real symptom.

Environment

• OS: Windows 11
• Node: 20.x
• Smithery CLI: 4.11.1
• @anthropic-ai/claude-code: latest via npm global