fix(script): mcpx-cleanup's Windows fix is unreachable on native Windows — process discovery and env reading still require POSIX ps #110

Finding

PR #107 fixed the temp-home comparison in script/mcpx-cleanup.ts for Windows path shapes, and its tests pass Windows-style inputs to the pure helpers — but the script can never reach those helpers on a native Windows install, because process discovery and environment reading are still POSIX-only:

• script/mcpx-cleanup.ts:74-92 (listDaemonPids, on current main 4e948420ce): the only branches are Linux (/proc) and "everything else", which runs Bun.spawnSync(["ps", "-eo", "pid=,command="]). Native Windows ships no ps command (the native tool is tasklist / Win32_Process), and this call has no try/catch.
• Verified locally with Bun 1.4.2: Bun.spawnSync with a command that is not on PATH throws Error: Executable not found in $PATH: "..." — it does not return empty output. So on native Windows the script crashes in listDaemonPids() (called unguarded from main() at script/mcpx-cleanup.ts:109) before any daemon is enumerated.
• script/mcpx-cleanup.ts:95-105 (readEnv): the non-Linux branch likewise shells out to ps eww -p <pid>. That call is inside a try/catch, so on Windows it would silently return an empty env map for every pid — HOME is never read, and isLeaked(undefined, ...) is false by design.
• The --apply stop path is also POSIX-shaped: script/mcpx-cleanup.ts:135 signals the process group with process.kill(-daemon.pid, sig), a Unix process-group idiom with no Windows equivalent in this code.

Net effect: the Windows half of #54 / PR #107 is tested only as pure string logic (isTempHome / isLeaked in script/mcpx-cleanup.test.ts). End-to-end, the cleanup remedy for leaked mcpx daemons still does not run on native Windows — it either throws an unhandled "Executable not found" error or (if enumeration were reached) reports no leaks — the same false-"all clear" class of problem #54 was filed for, one layer down.

Evidence

• PR fix(script): detect leaked mcpx daemons on macOS and Windows #107 (merged, merge commit 4e948420ce70129d977b2de3243b1d0856fb2f65, commit 32324e5a9f6bbefe62d5c739126d4b363317ad95): fix(script): detect leaked mcpx daemons on macOS and Windows #107 — title claims detection "on macOS and Windows"; its 12 tests are all pure-helper tests (bun test re-run in a scratch dir during review: 12 pass).
• script/mcpx-cleanup.ts:88 and :100 on current main (cross-checked via gh api contents): both non-Linux paths invoke ps; a grep for win32 in the file finds no platform branch for Windows (the only windows identifier is the path-shape flag inside isTempHome/normalize).
• Bun behaviour verified in a scratch script: Bun.spawnSync(["definitely-not-a-real-command-xyz", ...]) throws Error: Executable not found in $PATH.
• Single-repo: git ls-files | grep mcpx-cleanup finds the script only in this repo (checked developing-today/code, developing-today/openchamber, dezren39/nix — none), so no cross-repo set is owed.
• Deduped against open and closed issues: searches for tasklist, mcpx-cleanup ps, and cleanup Windows native return only closed fix: mcpx-cleanup script misses leaked daemons on macOS/Windows — temp-home check assumes a POSIX tmpdir with no trailing separator #54 / mcpx plugin leaks detached daemons from tests and short-lived processes: stable binary path, idle exit, test opt-out, cleanup script #14 (the comparison-layer fix) and unrelated fix(cli): Node build smoke cleanup rm throws EBUSY on Windows and fails a verified build #100; no open issue tracks the enumeration layer.

Why it matters

The script is the only remedy for mcpx daemons leaked by test runs and short-lived processes (#14). On macOS that remedy now works; on native Windows a user following the docs (packages/web/src/content/docs/cli.mdx: "run bun run script/mcpx-cleanup.ts") gets an unhandled crash or a false "No leaked mcpx daemons found." while detached daemons keep running MCP servers from a temp home — the false-confidence failure #54 called out.

Acceptance criteria

• On native Windows, bun run script/mcpx-cleanup.ts either actually enumerates mcpx daemon processes with their HOME (e.g. via tasklist / CIM Win32_Process, with the other-process environment-read limitation on Windows explicitly handled or documented), or exits with a clear, intentional "not supported on native Windows" message — never an unhandled Executable not found in $PATH: "ps" throw and never a false "No leaked mcpx daemons found."
• If Windows enumeration is implemented, the --apply stop path works without POSIX process-group signalling (no process.kill(-pid, ...) assumption), or --apply is explicitly gated with the same clear unsupported message.
• Platform dispatch is covered by a test (e.g. the platform/command selection is factored so a win32 case is asserted), so a future platform claim in this script is backed by an integration-level test and not only pure path-shape helpers.
• Linux and macOS dry-run behaviour is unchanged; the existing 12 helper tests in script/mcpx-cleanup.test.ts still pass.