Raised from an independent audit of #636 and confirmed against the workflow: no CI job exercises the MCP probe on Windows.
install-ps1 runs on windows-latest, but its own comment states why it stops short:
It deliberately does not require a healthy doctor: on Windows the hook-runtime probe spawns /bin/sh, which does not exist there, and the PreToolUse entry names commitlore while the shim is commitlore.cmd.
So a green install-ps1 says the installer works. It says nothing about whether the probe classifies commands correctly on Windows.
Two specific risks
1. Bare-command resolution ignores PATHEXT. commandPath() looks for a bare command as <PATH directory>/<command>. On Windows the executable is node.exe or commitlore.cmd, resolved through PATHEXT. spawn('node') can succeed while the precheck stats …\node, finds nothing, and returns command-not-found.
The consequence is the inverse of the defect #572 exists to fix: a registration that works would be reported broken, and doctor would tell a Windows user to repair something that is already correct.
2. Child-tree cleanup does not follow on Windows. The probe kills a detached process group, which POSIX honours. Windows terminates the direct child only, so a custom wrapper that spawns the real MCP server can leave that server running after the probe returns.
Acceptance
- an explicit path is checked with a filesystem stat; a bare command is left to the platform's own resolution and its
ENOENT classified from the spawn result
- a fixture whose
.mcp.json carries "command": "node" is probed on Windows and is not reported command-not-found
- a Windows fixture where the wrapper spawns a child MCP server leaves no descendant after the probe returns
- whatever job proves these runs on
windows-latest; a Linux or macOS run cannot stand in for it
Non-goals
No process-manager framework. A bounded platform helper is enough if one is needed at all.
Why this is filed rather than fixed inside #636
#636's scope is live MCP identity, and its evidence is real on the platforms CI actually exercises. Claiming Windows correctness from a green install-ps1 would be exactly the false-success this repository keeps closing. This issue holds the gap until something on windows-latest proves it.
Raised from an independent audit of #636 and confirmed against the workflow: no CI job exercises the MCP probe on Windows.
install-ps1runs onwindows-latest, but its own comment states why it stops short:So a green
install-ps1says the installer works. It says nothing about whether the probe classifies commands correctly on Windows.Two specific risks
1. Bare-command resolution ignores PATHEXT.
commandPath()looks for a bare command as<PATH directory>/<command>. On Windows the executable isnode.exeorcommitlore.cmd, resolved throughPATHEXT.spawn('node')can succeed while the precheck stats…\node, finds nothing, and returnscommand-not-found.The consequence is the inverse of the defect #572 exists to fix: a registration that works would be reported broken, and
doctorwould tell a Windows user to repair something that is already correct.2. Child-tree cleanup does not follow on Windows. The probe kills a detached process group, which POSIX honours. Windows terminates the direct child only, so a custom wrapper that spawns the real MCP server can leave that server running after the probe returns.
Acceptance
ENOENTclassified from the spawn result.mcp.jsoncarries"command": "node"is probed on Windows and is not reportedcommand-not-foundwindows-latest; a Linux or macOS run cannot stand in for itNon-goals
No process-manager framework. A bounded platform helper is enough if one is needed at all.
Why this is filed rather than fixed inside #636
#636's scope is live MCP identity, and its evidence is real on the platforms CI actually exercises. Claiming Windows correctness from a green
install-ps1would be exactly the false-success this repository keeps closing. This issue holds the gap until something onwindows-latestproves it.