fix(extension): Windows binary spawn must not depend on user-installed Node

Replaces the previous attempt (which assumed `node.exe` was on PATH —
true for devs, not for typical chat-IDE users) with a Node-independent
path that uses Cursor's bundled Electron runtime.

Mechanism: every Electron binary (Cursor.exe, Code.exe) can be invoked
as a plain Node interpreter by setting the env var
ELECTRON_RUN_AS_NODE=1. In the extension host `process.execPath` is the
absolute path to that Electron binary, so we always have it available.
This is the same pattern VS Code uses internally for language servers
and other Node subprocesses (vscode-languageclient,
vscode/extensions/typescript-language-features, etc.).

Three call surfaces fixed:

1. extension/src/spawn-binary.ts — used by search-mode toggle, backlog
   add/update, setup, status webview, auditor auth. Replaces
   `spawn("node", ...)` with `spawn(process.execPath, ...,
   { env: { ...process.env, ELECTRON_RUN_AS_NODE: "1" }})`.

2. extension/src/mcp-register.ts — the headline path. Registers MCP
   with `command: process.execPath, env: { ELECTRON_RUN_AS_NODE: "1" }`
   on Windows, so Cursor's MCP runner spawns Cursor.exe-as-Node when it
   starts the AXME MCP server.

3. extension/src/hooks-install.ts — Cursor's hook runner spawns hook
   commands via cmd.exe. We can't pass env vars through hooks.json
   (the schema is just command/type/timeout). On Windows we now write
   a tiny `~/.cursor/axme-hook.cmd` wrapper at install time that sets
   ELECTRON_RUN_AS_NODE=1 + invokes Cursor.exe with the bundled binary
   as argv[0]. hooks.json points at this wrapper. uninstallUserHooks()
   deletes the wrapper alongside the JSON entries.

ELECTRON_RUN_AS_NODE behaviour is documented at:
https://www.electronjs.org/docs/latest/api/environment-variables#electron_run_as_node

Linux + macOS paths unchanged — shebang shim works natively.

Reported by @geobelsky after the v0.1.0 install failed silently on a
Windows machine without Node, leaving every MCP tool unreachable.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: George-iam

extension/src/hooks-install.ts

@@ -21,7 +21,7 @@
  * added entries are preserved verbatim.
  */
 
-import { existsSync, mkdirSync, readFileSync, writeFileSync } from "node:fs";
+import { existsSync, mkdirSync, readFileSync, unlinkSync, writeFileSync } from "node:fs";
 import { dirname, join } from "node:path";
 import { homedir } from "node:os";
 import { IdeKind } from "./ide-detect.js";
@@ -58,19 +58,65 @@ function quote(s: string): string {
   return `"${s.replace(/"/g, '\\"')}"`;
 }
 
+/**
+ * Path to the Windows wrapper script. Lives next to hooks.json so a
+ * single uninstall sweep deletes both. The wrapper is a one-liner .cmd
+ * that sets ELECTRON_RUN_AS_NODE=1 and invokes Cursor.exe as a Node
+ * interpreter on the bundled binary — see buildHookCommand() rationale
+ * below for the full explanation.
+ */
+function windowsHookWrapperPath(): string {
+  return join(homedir(), ".cursor", "axme-hook.cmd");
+}
+
+/**
+ * Write the Windows .cmd wrapper that lets Cursor's hook runner invoke
+ * our shebang-shim binary without requiring `node.exe` on PATH. Returns
+ * the wrapper path (caller writes it into the hook command string).
+ *
+ * The wrapper captures the Cursor.exe path (process.execPath in the
+ * extension host) AND the absolute path to the bundled binary, so it
+ * works even when the user's PATH lacks Node and even when Cursor is
+ * installed in a non-standard location. ELECTRON_RUN_AS_NODE=1 tells
+ * Electron to behave as a plain Node interpreter; same trick VS Code
+ * uses internally for language servers.
+ */
+function writeWindowsHookWrapper(binary: string): string {
+  const path = windowsHookWrapperPath();
+  // cmd.exe parser quirks:
+  //   - `@echo off` silences the prompt echo
+  //   - `setlocal` scopes the env var to this script invocation
+  //   - `%*` forwards all caller args verbatim (with quoting preserved)
+  // The Cursor.exe path comes from process.execPath at install time —
+  // if Cursor relocates, user re-runs setup and we rewrite this file.
+  const content =
+    `@echo off\r\n` +
+    `setlocal\r\n` +
+    `set ELECTRON_RUN_AS_NODE=1\r\n` +
+    `"${process.execPath}" "${binary}" %*\r\n`;
+  mkdirSync(dirname(path), { recursive: true });
+  writeFileSync(path, content, "utf-8");
+  log(`Hooks: wrote Windows wrapper at ${path}`);
+  return path;
+}
+
 function buildHookCommand(binary: string, hookName: string): string {
   // No --workspace flag — handler core resolves it from stdin
   // workspace_roots[0] (PR #129 commit d267b82).
   //
   // Cross-platform: the bundled binary is a shebang shim (`#!/usr/bin/env
   // node` + CJS payload). POSIX honors the shebang and runs it directly.
   // Windows ignores shebangs and fails with ENOENT when cmd.exe / Cursor
-  // tries to exec the file. On Windows we prefix the command with `node`,
-  // which Cursor users on Windows typically have on PATH (standard dev
-  // setup). Falls through gracefully — Cursor's hook runner uses cmd.exe
-  // /c so PATH lookup works the same as in any terminal.
+  // tries to exec the file. We do NOT rely on Node being on PATH (most
+  // Windows chat-IDE users do not have it) — instead, the .cmd wrapper
+  // we write at install time invokes Cursor.exe with the
+  // ELECTRON_RUN_AS_NODE=1 env var, making Cursor's bundled Electron
+  // behave as a Node interpreter for our JS payload. The wrapper
+  // captures absolute Cursor.exe + binary paths at install time so
+  // the hook fires the same way regardless of the user's shell config.
   if (process.platform === "win32") {
-    return `node ${quote(binary)} hook ${hookName} --ide cursor`;
+    const wrapper = writeWindowsHookWrapper(binary);
+    return `${quote(wrapper)} hook ${hookName} --ide cursor`;
   }
   return `${quote(binary)} hook ${hookName} --ide cursor`;
 }
@@ -157,4 +203,16 @@ export function uninstallUserHooks(): void {
   } catch (err) {
     logError("Hooks: uninstall failed", err);
   }
+  // Drop the Windows .cmd wrapper (no-op on POSIX — the file never existed).
+  if (process.platform === "win32") {
+    const wrapper = windowsHookWrapperPath();
+    if (existsSync(wrapper)) {
+      try {
+        unlinkSync(wrapper);
+        log(`Hooks: removed Windows wrapper ${wrapper}`);
+      } catch (err) {
+        logError("Hooks: wrapper removal failed", err);
+      }
+    }
+  }
 }

extension/src/mcp-register.ts

@@ -58,18 +58,26 @@ export async function registerMcpServer(
   // execute the file as a PE binary → Cursor's MCP runner does
   // `spawn(command, args)` directly and gets ENOENT, which surfaces in
   // the chat as "MCP server does not exist … No MCP servers available."
-  // The fix mirrors what spawn-binary.ts does for our own child_process
-  // spawns: register with command="node" and the binary as the first
-  // argv on Windows, so Node loads the JS payload regardless of the
-  // file extension. Linux + macOS keep the direct path.
+  //
+  // The fix uses Cursor's own Electron binary as the Node interpreter.
+  // `process.execPath` in the extension host = path to Cursor.exe (or
+  // Code.exe in VS Code), which is an Electron binary that can run as
+  // plain Node when invoked with the env var `ELECTRON_RUN_AS_NODE=1`.
+  // This eliminates the dependency on the user having `node.exe` on
+  // PATH — most Windows users of a chat-agent IDE will not. Same
+  // pattern VS Code uses internally for language servers and other
+  // Node subprocesses.
+  //
+  // Documented: https://www.electronjs.org/docs/latest/api/environment-variables#electron_run_as_node
   const isWindows = process.platform === "win32";
-  const command = isWindows ? "node" : binary;
+  const command = isWindows ? process.execPath : binary;
   const args = isWindows ? [binary, ...serveArgs] : serveArgs;
+  const env: Record<string, string> = isWindows ? { ELECTRON_RUN_AS_NODE: "1" } : {};
   cursor.registerServer({
     name: "axme",
-    server: { command, args, env: {} },
+    server: { command, args, env },
   });
-  log(`MCP: registered 'axme' (command=${command}, binary=${binary}, workspace=${workspaceRoot ?? "(none)"})`);
+  log(`MCP: registered 'axme' (command=${command}, binary=${binary}, workspace=${workspaceRoot ?? "(none)"}, electron-as-node=${isWindows ? "yes" : "no"})`);
   // Cursor needs ~3s to process the registration before tools become
   // available to the chat agent. Verified empirically against the
   // browser-devtools-mcp reference implementation.

extension/src/spawn-binary.ts

@@ -7,10 +7,15 @@
  * and rejects the file with ENOENT / UNKNOWN when treated as an
  * executable, regardless of the .exe / .cjs file-extension we ship.
  *
- * The fix on Windows is to invoke via `node <binary>` so Node executes
- * the JS payload directly. Cursor users on Windows nearly always have
- * Node installed for dev work; we rely on `node` being on PATH (cmd.exe
- * /c looks up commands the same way an interactive shell does).
+ * The fix on Windows: invoke via Cursor's own Electron binary
+ * (`process.execPath`) with the env var `ELECTRON_RUN_AS_NODE=1`. That
+ * makes Cursor.exe behave as a plain Node interpreter and execute the
+ * JS payload. We DO NOT rely on the user having `node.exe` on PATH —
+ * most Windows users of a chat-agent IDE will not.
+ *
+ * This is the same pattern VS Code itself uses internally for spawning
+ * Node subprocesses (e.g. language servers via vscode-languageclient).
+ * Documented at https://www.electronjs.org/docs/latest/api/environment-variables#electron_run_as_node
  *
  * Every spawn of the bundled binary in the extension should go through
  * this helper. A direct `spawn(binary, args)` will work on Linux + macOS
@@ -40,7 +45,10 @@ export function spawnBinary(
 ): ChildProcess {
   const opts = options ?? {};
   if (process.platform === "win32") {
-    return spawn("node", [binary, ...args], opts);
+    return spawn(process.execPath, [binary, ...args], {
+      ...opts,
+      env: { ...process.env, ...(opts.env as NodeJS.ProcessEnv | undefined), ELECTRON_RUN_AS_NODE: "1" },
+    });
   }
   return spawn(binary, args, opts);
 }