fix(cli): support Windows project daemon launches

[HowardBraham]

Context

The mm CLI could not reliably launch a project's TypeScript daemon on Windows. The CLI bypasses the package manager when it starts the daemon, so it attempted to execute the POSIX-style node_modules/.bin/tsx shim instead of Windows' tsx.cmd launcher. Relative extension paths also reached the consumer unchanged, allowing Chromium to resolve them from its executable directory rather than the target project.

Cold Windows daemon startup could occasionally take longer than the CLI's 10-second readiness deadline. In addition, the docs did not clearly distinguish bare mm usage from project-local package-manager invocation.

Solution

• Resolve package-manager runtime shims to .cmd on Windows and launch them with the required shell mode.
• Preserve direct, shell-free execution for POSIX runtimes and runtime: node.
• Apply the launch behavior consistently to daemon auto-start and foreground and background mm serve.
• Resolve --extension-path relative to the selected project root while preserving absolute paths.
• Increase daemon readiness polling from 10 seconds to 30 seconds.
• Document that global installs use mm, while project dependencies use yarn mm.

Validation

• yarn vitest src/cli/mm.test.ts --no-coverage
• yarn lint:eslint
• yarn build
• Windows local-package smoke test against MetaMask Extension:
  • linked client-mcp-core with yarn link
  • launched with relative --extension-path dist/chrome
  • verified both headed and headless extension startup
  • ran describe-screen, an unlock interaction, and cleanup --shutdown
  • confirmed .mm-server and .mm-server.lock were removed

Changelog

Fixed Windows support for launching project-local mm daemons.

[Copilot]

🟡 Changes recommended

Shell spawning breaks Windows project paths containing spaces, and a new test leaks environment state.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Updates daemon launching for Windows and clarifies local versus global CLI usage.

Changes:

• Adds Windows .cmd runtime resolution and 30-second startup polling.
• Resolves extension paths relative to the project root.
• Documents project-local and global invocation.

File summaries

File	Description
src/cli/mm.ts	Updates daemon startup and path resolution.
src/cli/mm.test.ts	Tests runtime and extension-path behavior.
README.md	Clarifies CLI invocation methods.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 2
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

⚪ Unable to assess

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 1
• Review effort level: Balanced

[Copilot]

⚪ Unable to assess

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 2
• Review effort level: Balanced

[Copilot]

⚪ Unable to assess

Review details

Suppressed comments (1)

src/cli/mm.ts:1431

• This assumes every configured Windows TypeScript runner is a JavaScript entry point. A valid native runner shim (for example, one invoking a .exe) will match this regex, but the returned command then asks Node to parse that executable and daemon startup fails. The runtime API is an arbitrary runner name, and the POSIX path preserves the shim's own interpreter semantics. Execute the .cmd shim through the Windows shell (and carry that requirement to all three spawn sites) rather than extracting an entry point and forcing process.execPath.

    return {
      command: process.execPath,
      args: [path.win32.resolve(path.win32.dirname(binPath), '..', entryPoint)],

• Files reviewed: 5/5 changed files
• Comments generated: 1
• Review effort level: Balanced

[Copilot]

⚪ Unable to assess

Review details

• Files reviewed: 6/6 changed files
• Comments generated: 1
• Review effort level: Balanced