Skip to content

The MCP probe's Windows behaviour is unverified: PATHEXT resolution and child-tree cleanup #640

Description

@MongLong0214

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions