fix: detect and launch AI CLIs correctly on Windows (#85)

[Yashasvi2229]

What

Fix AI-CLI detection and launch on Windows. mex sync and
mex setup never
detected an installed AI CLI on Windows, so they silently
fell back to
copy-paste prompt mode even when Claude Code / Codex were
installed.

• Detection used which, which doesn't exist on Windows
  (the built-in is
  where). execSync("which <cmd>") always threw → every
  tool reported as not
  installed. Added isCliAvailable() (src/cli-tools.ts):
  probes with where
  on Windows, which elsewhere.
• Launch used spawn/spawnSync, which throw ENOENT
  on the Windows
  claude.cmd wrapper. Switched the launch sites to
  cross-spawn, which
  resolves .cmd/.bat wrappers and escapes args correctly
  while keeping the
  multi-line prompt as a single argv element. (The naive
  shell: true is worse —
  Node concatenates args unescaped, DEP0190, shattering the
  prompt.)
• Robustness: runToolInteractive treated status === null (a spawn
  failure) as success, swallowing launch errors. Now returns
  false on
  result.error and only treats status === 0 as success.

Why

Closes #85

On Windows, the which-based detection made interactive
sync/setup unusable —
users were forced into copy-paste mode regardless of which
AI CLI they had
installed.

Type of change

• Bug fix
• New feature
• Refactor
• Docs
• CI/Tooling

How to test

1. On Windows with claude installed and on PATH, run mex sync in a scaffold
   with drift → it now detects "Claude Code" instead of
   printing
   "No supported AI CLI detected. Falling back to prompts
   mode."
2. Choose interactive (1) → Claude Code launches with the
   fix prompt (no
   spawn claude ENOENT).
3. On macOS/Linux, behavior is unchanged. npm test → all
   240 tests pass.

Checklist

Checklist

• Tests pass (npm test)
• No breaking changes (or documented below)
• Tested locally with a real project

[theDakshJaitly]

Thanks for this — the diagnosis and fix are spot on, and switching to cross-spawn over shell: true is the right call. Nice that the new error handling also fixes the timeout-reported-as-success bug in runToolInteractive, not just the Windows path.

A few things before merge:

1. Add a test for the runToolInteractive return-value logic. It's the riskiest change in this PR and is currently untested — isCliAvailable has coverage, but the sync return logic doesn't. Mocking crossSpawn.sync to cover:

• { status: 0 } -> true
• { status: 1 } -> false
• { error: new Error(), status: null } -> false (the timeout / ENOENT case)
• { status: null, signal: "SIGINT" } -> false

would lock in the intended semantics.

3. Trim the lockfile churn. package-lock.json picked up a lot of unrelated "peer": true markers on existing packages (react, esbuild, typescript, postcss, vite-node, yaml, ...) beyond the cross-spawn additions — looks like a different npm version re-resolved the tree. Could you regenerate the lockfile with the project's npm version so the diff is limited to the cross-spawn entries, and confirm npm ci still resolves cleanly?

5. Wrap the launchClaude call. In src/setup/index.ts, await launchClaude(prompt) isn't in a try/catch, so a launch failure or a non-zero claude exit rejects and surfaces as an unhandled rejection. Since this PR is specifically about hardening the launch path, catching it to print a friendly message would round things out.

The other points from review (the user-interrupt behavior change, the @types/cross-spawn major-version lag) are non-blocking and fine as-is.

[theDakshJaitly]

LGTM