maqcli 0.6.6 → 0.7.0

package/dist/core/exec.d.ts

@@ -4,7 +4,47 @@
  * Uses spawn with an explicit argument array and shell:false so user/model
  * provided values can never be interpreted by a shell. This is the single
  * chokepoint for running worker CLIs and raw commands.
+ *
+ * WINDOWS BATCH-SHIM HANDLING (the general fix, applied once here)
+ * ------------------------------------------------------------------
+ * Node's `spawn(cmd, args, {shell:false})` can only directly execute native
+ * executables. On Windows, a great many "binaries" resolve to `.cmd`/`.bat`
+ * (npm's own global-install shims — `codex.cmd`, `gemini.cmd`, `npm.cmd`, …)
+ * or `.ps1` files, which are NOT directly executable — spawning them without
+ * a command interpreter throws EINVAL/ENOENT/UNKNOWN regardless of the target
+ * name. This bit both the worker-CLI dispatch path (execute.ts → CliProvider)
+ * and the self-updater before this fix landed.
+ *
+ * The fix (the same approach the `cross-spawn` ecosystem package uses):
+ * detect a `.cmd`/`.bat`/`.ps1` target and transparently re-target the spawn
+ * to `cmd.exe /c <target> <args...>`, passing the target and each argument as
+ * SEPARATE array elements — never a hand-assembled command-line string. This
+ * still goes through `child_process.spawn` with `shell:false` at the Node
+ * API level; cmd.exe is the one fixed, trusted executable being spawned, and
+ * Node's own per-argument Windows escaping (which correctly handles spaces,
+ * quotes, and metacharacters within a single argument) does the rest. Every
+ * caller of execSafe/execStream gets this for free; nothing above this layer
+ * needs to know.
+ */
+/**
+ * Resolve the effective spawn target for Windows batch/PowerShell shims.
+ * Returns the original {cmd, args} unchanged on POSIX or for native
+ * executables; re-targets through cmd.exe otherwise.
+ *
+ * Critically, the shim's arguments are passed as SEPARATE array elements to
+ * cmd.exe (`/c`, "<shim>", ...args), not hand-assembled into one big quoted
+ * string. Node's own spawn implementation already knows how to correctly
+ * quote each array element for a Windows command line (including embedded
+ * spaces/quotes); building our own single-string command line and adding
+ * `/d /s` on top double-quotes it and corrupts paths with spaces (verified:
+ * it mangled "C:\Program Files\nodejs\npm.CMD" into an unrecognized string).
+ * Letting spawn's own per-argument escaping do the work, one level of
+ * cmd.exe indirection, is both simpler and correct.
  */
+export declare function resolveSpawnTarget(cmd: string, args: string[]): {
+    cmd: string;
+    args: string[];
+};
 export interface ExecOptions {
     cwd?: string;
     /** Milliseconds before the child is killed. */

package/dist/core/exec.js

@@ -4,9 +4,52 @@
  * Uses spawn with an explicit argument array and shell:false so user/model
  * provided values can never be interpreted by a shell. This is the single
  * chokepoint for running worker CLIs and raw commands.
+ *
+ * WINDOWS BATCH-SHIM HANDLING (the general fix, applied once here)
+ * ------------------------------------------------------------------
+ * Node's `spawn(cmd, args, {shell:false})` can only directly execute native
+ * executables. On Windows, a great many "binaries" resolve to `.cmd`/`.bat`
+ * (npm's own global-install shims — `codex.cmd`, `gemini.cmd`, `npm.cmd`, …)
+ * or `.ps1` files, which are NOT directly executable — spawning them without
+ * a command interpreter throws EINVAL/ENOENT/UNKNOWN regardless of the target
+ * name. This bit both the worker-CLI dispatch path (execute.ts → CliProvider)
+ * and the self-updater before this fix landed.
+ *
+ * The fix (the same approach the `cross-spawn` ecosystem package uses):
+ * detect a `.cmd`/`.bat`/`.ps1` target and transparently re-target the spawn
+ * to `cmd.exe /c <target> <args...>`, passing the target and each argument as
+ * SEPARATE array elements — never a hand-assembled command-line string. This
+ * still goes through `child_process.spawn` with `shell:false` at the Node
+ * API level; cmd.exe is the one fixed, trusted executable being spawned, and
+ * Node's own per-argument Windows escaping (which correctly handles spaces,
+ * quotes, and metacharacters within a single argument) does the rest. Every
+ * caller of execSafe/execStream gets this for free; nothing above this layer
+ * needs to know.
  */
 import { spawn } from "node:child_process";
 import { scrubEnv } from "./security.js";
+const WINDOWS_SHIM_EXT = /\.(cmd|bat|ps1)$/i;
+/**
+ * Resolve the effective spawn target for Windows batch/PowerShell shims.
+ * Returns the original {cmd, args} unchanged on POSIX or for native
+ * executables; re-targets through cmd.exe otherwise.
+ *
+ * Critically, the shim's arguments are passed as SEPARATE array elements to
+ * cmd.exe (`/c`, "<shim>", ...args), not hand-assembled into one big quoted
+ * string. Node's own spawn implementation already knows how to correctly
+ * quote each array element for a Windows command line (including embedded
+ * spaces/quotes); building our own single-string command line and adding
+ * `/d /s` on top double-quotes it and corrupts paths with spaces (verified:
+ * it mangled "C:\Program Files\nodejs\npm.CMD" into an unrecognized string).
+ * Letting spawn's own per-argument escaping do the work, one level of
+ * cmd.exe indirection, is both simpler and correct.
+ */
+export function resolveSpawnTarget(cmd, args) {
+    if (process.platform !== "win32" || !WINDOWS_SHIM_EXT.test(cmd)) {
+        return { cmd, args };
+    }
+    return { cmd: "cmd.exe", args: ["/c", cmd, ...args] };
+}
 /**
  * Run a command safely. `cmd` is the binary, `args` are passed verbatim.
  * Never pass a full command string here — that is what enables injection.
@@ -16,7 +59,8 @@ export function execSafe(cmd, args = [], opts = {}) {
     return new Promise((resolve) => {
         const baseEnv = opts.env ?? process.env;
         const env = opts.scrubSecrets === false ? baseEnv : scrubEnv(baseEnv, opts.secretAllowlist);
-        const child = spawn(cmd, args, {
+        const target = resolveSpawnTarget(cmd, args);
+        const child = spawn(target.cmd, target.args, {
             cwd: opts.cwd ?? process.cwd(),
             env,
             shell: false,
@@ -83,7 +127,8 @@ export function execStream(cmd, args = [], opts = {}) {
     return new Promise((resolve) => {
         const baseEnv = opts.env ?? process.env;
         const env = opts.scrubSecrets === false ? baseEnv : scrubEnv(baseEnv, opts.secretAllowlist);
-        const child = spawn(cmd, args, {
+        const target = resolveSpawnTarget(cmd, args);
+        const child = spawn(target.cmd, target.args, {
             cwd: opts.cwd ?? process.cwd(),
             env,
             shell: false,

package/dist/core/launcher.js

@@ -353,7 +353,7 @@ async function connectMobile(rl) {
 async function launchUi(authKey) {
     // Reuse the daemon; open its landing page. Import lazily to avoid a cycle.
     const { createDaemon } = await import("../server/daemon.js");
-    const daemon = createDaemon({ token: authKey, version: "0.6.6" });
+    const daemon = createDaemon({ token: authKey, version: "0.7.0" });
     try {
         const { host, port } = await daemon.listen();
         const url = `http://${host}:${port}/`;

package/dist/core/update.d.ts

@@ -8,37 +8,21 @@
  * default-deny egress posture (core/security.ts) — it only ever talks to the
  * npm registry, and only when the user explicitly runs this command.
  *
- * THE WINDOWS FILE-LOCK PROBLEM AND ITS FIX
- * ------------------------------------------
- * `npm install -g` has to overwrite the `maq`/`maqcli` shim and the running
- * package's files. If that `npm install` runs as a CHILD of the currently
- * executing `maq` process (i.e. `maq` spawns it and waits), Windows can hold
- * file/handle locks on the very binary being replaced for as long as the
- * parent process tree is alive — npm's overwrite can fail or silently leave a
- * half-updated install. Waiting-for-the-child is the actual cause, not npm
- * itself.
- *
- * The fix: spawn the npm install fully DETACHED (`detached: true`,
- * `stdio: "ignore"`, `.unref()`) so it is not a child of `maq` in any way
- * meaningful to the OS's lock semantics, then have `maq` EXIT IMMEDIATELY
- * instead of waiting on it. By the time npm actually touches the shim files,
- * the process that used to hold them has already terminated. This is the same
- * pattern self-updating CLIs (rustup, deno, bun) use on Windows.
- *
- * THE SEPARATE "CAN'T EVEN LAUNCH NPM" PROBLEM AND ITS FIX
- * ------------------------------------------------------------
- * `child_process.spawn(cmd, args, {shell:false})` — which execSafe always
- * uses, deliberately, to avoid shell-injection — cannot execute `npm`
- * directly on Windows AT ALL, regardless of which name you pass. The `npm` on
- * PATH there is `npm.cmd`, a batch-file shim, and Windows can only run batch
- * files through a command interpreter; spawning it as a bare child process
- * throws ENOENT (name not found as-is) or EINVAL (found but not directly
- * executable), never succeeds. The fix is `runNpm()` below: on Windows it
- * routes through `cmd.exe /c "npm ..."` (still shell:false at the
- * child_process level — cmd.exe is the fixed, trusted executable being
- * spawned; the args passed to IT are our own literal strings, never
- * unsanitized input, so this does not reopen the shell-injection risk
- * execSafe exists to close).
+ * TWO WINDOWS PROBLEMS, BOTH FIXED AT THE ROOT NOW
+ * ---------------------------------------------------
+ * 1. "spawn npm ENOENT/EINVAL" — `npm` on PATH is `npm.cmd`, a batch shim;
+ *    `child_process.spawn(shell:false)` cannot execute batch files directly.
+ *    Fixed generically in exec.ts's `resolveSpawnTarget()` — it detects
+ *    .cmd/.bat/.ps1 targets and transparently re-targets through
+ *    `cmd.exe /d /s /c`, as an argv array (never a hand-built shell string).
+ *    Every execSafe/execStream caller gets this for free; this module no
+ *    longer needs its own cmd.exe-wrapping or quoting logic at all.
+ * 2. The file-lock problem — `npm install -g` has to overwrite the running
+ *    `maq` binary's own files. If that install runs as a CHILD that `maq`
+ *    waits on, Windows can hold locks on those files for the wait's entire
+ *    duration. Fixed by spawning npm with `detached: true` + `.unref()` and
+ *    returning immediately instead of awaiting it — nothing above this layer
+ *    holds a lock on anything by the time npm actually touches the files.
  */
 import { spawn } from "node:child_process";
 export interface VersionInfo {
@@ -54,8 +38,9 @@ export declare function fetchLatestVersion(registryUrl?: string, timeoutMs?: num
 /** Compare the running version against the registry; never throws. */
 export declare function checkForUpdate(currentVersion: string): Promise<VersionInfo>;
 /**
- * Run an npm subcommand safely and portably. See the module doc's second
- * section for why this can't just be `execSafe("npm", args)` on Windows.
+ * Run an npm subcommand synchronously and capture its output. Safe on
+ * Windows because execSafe's resolveSpawnTarget transparently handles the
+ * `.cmd` shim; no manual cmd.exe wrapping needed here anymore.
  */
 export declare function runNpm(args: string[], opts?: {
     timeoutMs?: number;
@@ -64,39 +49,6 @@ export declare function runNpm(args: string[], opts?: {
     stdout: string;
     stderr: string;
 }>;
-/**
- * Build the OS-appropriate command to run `npm install -g maqcli@<version>`
- * fully detached from the current process (see module doc for why).
- *
- * On Windows, `cmd.exe /c "npm install..."` alone is NOT enough: even with
- * `detached: true` + `.unref()` on the Node side, the child stays tied to the
- * parent's console/job object, and it dies the moment the parent's console
- * closes (a long-standing Node behavior on Windows — nodejs/node#5614). The
- * fix is to have cmd.exe launch the real work via the `start` builtin, which
- * creates a genuinely independent process outside the parent's job object.
- *
- * `start`'s own command-line parsing is notoriously fragile with nested
- * quotes (redirection operators and quoted paths inside a quoted inner
- * command reliably break it). Rather than fight cmd.exe's quoting rules, we
- * write the actual work to a small, disposable .bat/.sh script on disk and
- * have `start`/the shell launch THAT — no nested quoting at all.
- */
-export declare function detachedInstallCommand(version: string, logPath: string, platform?: NodeJS.Platform): {
-    cmd: string;
-    args: string[];
-    scriptPath: string;
-    scriptContent: string;
-    cleanupPath?: string;
-    cleanupContent?: string;
-};
-/**
- * Launch the update fully detached and return immediately — the caller
- * (cmdUpdate) should print guidance and exit right away rather than await
- * anything else, which is what avoids the Windows file-lock failure mode.
- * `spawner` is injectable for tests so nothing is actually spawned there.
- * `writer` is injectable so tests don't touch the real filesystem either.
- */
-export declare function launchDetachedUpdate(version: string, logPath: string, spawner?: typeof spawn, writer?: (path: string, content: string) => void): number | undefined;
 export interface UpdateOutcome {
     ok: boolean;
     message: string;
@@ -106,16 +58,20 @@ export interface UpdateOutcome {
     /** Path a caller can inspect afterward to see the detached install's own npm output. */
     logPath?: string;
 }
+/**
+ * Launch `npm install -g maqcli@<version>` fully detached (survives this
+ * process exiting) and pipe its output to a log file for later inspection.
+ * `spawner` is injectable for tests so nothing is actually spawned there.
+ */
+export declare function launchDetachedUpdate(version: string, logPath: string, spawner?: typeof spawn): number | undefined;
 /**
  * Perform the update: check the registry, and if a newer version exists,
  * launch `npm install -g maqcli@<latest>` DETACHED from this process (see the
- * module doc — this is what avoids the Windows file-lock failure mode where
- * npm can't overwrite files the running `maq` process still holds open).
+ * module doc — this is what avoids the Windows file-lock failure mode).
  *
  * The detached path is the default and recommended flow: this function
  * returns as soon as the install is launched; it does not wait for npm to
- * finish, because waiting would defeat the point (the parent would still be
- * alive, still holding the lock, for the whole duration).
+ * finish, because waiting would defeat the point.
  *
  * `opts.wait: true` (used by tests, and by --wait for a CI/non-interactive
  * caller that can tolerate the lock risk) runs synchronously instead, so the
@@ -131,14 +87,9 @@ export declare function performUpdate(currentVersion: string, opts?: {
         stderr: string;
     }>;
     spawner?: typeof spawn;
-    writer?: (path: string, content: string) => void;
     logPath?: string;
 }): Promise<UpdateOutcome>;
-/**
- * Read a detached update's log file (best-effort). Used by `maq update
- * --status` to show what the background install actually did, since the
- * `maq update` invocation that launched it already exited.
- */
+/** Read a detached update's log file (best-effort). Used by `maq update --status`. */
 export declare function readUpdateLog(logPath: string): Promise<string | null>;
 /**
  * Ask npm what is ACTUALLY installed globally right now (ground truth, not

package/dist/core/update.js

@@ -8,43 +8,28 @@
  * default-deny egress posture (core/security.ts) — it only ever talks to the
  * npm registry, and only when the user explicitly runs this command.
  *
- * THE WINDOWS FILE-LOCK PROBLEM AND ITS FIX
- * ------------------------------------------
- * `npm install -g` has to overwrite the `maq`/`maqcli` shim and the running
- * package's files. If that `npm install` runs as a CHILD of the currently
- * executing `maq` process (i.e. `maq` spawns it and waits), Windows can hold
- * file/handle locks on the very binary being replaced for as long as the
- * parent process tree is alive — npm's overwrite can fail or silently leave a
- * half-updated install. Waiting-for-the-child is the actual cause, not npm
- * itself.
- *
- * The fix: spawn the npm install fully DETACHED (`detached: true`,
- * `stdio: "ignore"`, `.unref()`) so it is not a child of `maq` in any way
- * meaningful to the OS's lock semantics, then have `maq` EXIT IMMEDIATELY
- * instead of waiting on it. By the time npm actually touches the shim files,
- * the process that used to hold them has already terminated. This is the same
- * pattern self-updating CLIs (rustup, deno, bun) use on Windows.
- *
- * THE SEPARATE "CAN'T EVEN LAUNCH NPM" PROBLEM AND ITS FIX
- * ------------------------------------------------------------
- * `child_process.spawn(cmd, args, {shell:false})` — which execSafe always
- * uses, deliberately, to avoid shell-injection — cannot execute `npm`
- * directly on Windows AT ALL, regardless of which name you pass. The `npm` on
- * PATH there is `npm.cmd`, a batch-file shim, and Windows can only run batch
- * files through a command interpreter; spawning it as a bare child process
- * throws ENOENT (name not found as-is) or EINVAL (found but not directly
- * executable), never succeeds. The fix is `runNpm()` below: on Windows it
- * routes through `cmd.exe /c "npm ..."` (still shell:false at the
- * child_process level — cmd.exe is the fixed, trusted executable being
- * spawned; the args passed to IT are our own literal strings, never
- * unsanitized input, so this does not reopen the shell-injection risk
- * execSafe exists to close).
+ * TWO WINDOWS PROBLEMS, BOTH FIXED AT THE ROOT NOW
+ * ---------------------------------------------------
+ * 1. "spawn npm ENOENT/EINVAL" — `npm` on PATH is `npm.cmd`, a batch shim;
+ *    `child_process.spawn(shell:false)` cannot execute batch files directly.
+ *    Fixed generically in exec.ts's `resolveSpawnTarget()` — it detects
+ *    .cmd/.bat/.ps1 targets and transparently re-targets through
+ *    `cmd.exe /d /s /c`, as an argv array (never a hand-built shell string).
+ *    Every execSafe/execStream caller gets this for free; this module no
+ *    longer needs its own cmd.exe-wrapping or quoting logic at all.
+ * 2. The file-lock problem — `npm install -g` has to overwrite the running
+ *    `maq` binary's own files. If that install runs as a CHILD that `maq`
+ *    waits on, Windows can hold locks on those files for the wait's entire
+ *    duration. Fixed by spawning npm with `detached: true` + `.unref()` and
+ *    returning immediately instead of awaiting it — nothing above this layer
+ *    holds a lock on anything by the time npm actually touches the files.
  */
 import { spawn } from "node:child_process";
 import { tmpdir } from "node:os";
 import { join } from "node:path";
-import { writeFileSync, chmodSync } from "node:fs";
+import { openSync } from "node:fs";
 import { execSafe } from "./exec.js";
+import { whichBin } from "./registry.js";
 /** Parse "x.y.z" into a comparable tuple; non-numeric parts sort as 0. */
 function parseSemver(v) {
     const parts = v.replace(/^v/, "").split(".").map((p) => parseInt(p, 10));
@@ -82,101 +67,51 @@ export async function checkForUpdate(currentVersion) {
         return { current: currentVersion, latest: null, upToDate: true, error: e.message };
     }
 }
-/**
- * Run an npm subcommand safely and portably. See the module doc's second
- * section for why this can't just be `execSafe("npm", args)` on Windows.
- */
-export async function runNpm(args, opts = {}) {
-    if (process.platform === "win32") {
-        // Every element here is our own literal string (package name, flags) —
-        // never unsanitized user input — so building one cmd.exe command line is
-        // safe. Defensively quote anything with whitespace anyway.
-        const cmdLine = ["npm", ...args].map((a) => (/\s/.test(a) ? `"${a}"` : a)).join(" ");
-        return execSafe("cmd.exe", ["/c", cmdLine], opts);
-    }
-    return execSafe("npm", args, opts);
+/** Resolve the real npm binary path once; falls back to the bare name (POSIX is fine with that). */
+function resolveNpmPath() {
+    return whichBin("npm") ?? "npm";
 }
 /**
- * Build the OS-appropriate command to run `npm install -g maqcli@<version>`
- * fully detached from the current process (see module doc for why).
- *
- * On Windows, `cmd.exe /c "npm install..."` alone is NOT enough: even with
- * `detached: true` + `.unref()` on the Node side, the child stays tied to the
- * parent's console/job object, and it dies the moment the parent's console
- * closes (a long-standing Node behavior on Windows — nodejs/node#5614). The
- * fix is to have cmd.exe launch the real work via the `start` builtin, which
- * creates a genuinely independent process outside the parent's job object.
- *
- * `start`'s own command-line parsing is notoriously fragile with nested
- * quotes (redirection operators and quoted paths inside a quoted inner
- * command reliably break it). Rather than fight cmd.exe's quoting rules, we
- * write the actual work to a small, disposable .bat/.sh script on disk and
- * have `start`/the shell launch THAT — no nested quoting at all.
+ * Run an npm subcommand synchronously and capture its output. Safe on
+ * Windows because execSafe's resolveSpawnTarget transparently handles the
+ * `.cmd` shim; no manual cmd.exe wrapping needed here anymore.
  */
-export function detachedInstallCommand(version, logPath, platform = process.platform) {
-    const pkg = `maqcli@${version}`;
-    if (platform === "win32") {
-        const scriptPath = join(tmpdir(), `maq-update-${Date.now()}.bat`);
-        const cleanupPath = join(tmpdir(), `maq-update-cleanup-${Date.now()}.bat`);
-        // The install script does NOT try to delete itself — a .bat can't
-        // reliably remove the file cmd.exe is actively interpreting. Instead it
-        // launches this second, separate cleanup script (detached, its own
-        // process) once npm finishes; THAT script deletes both files after a
-        // short delay, by which point neither is open by anything.
-        const scriptContent = [
-            "@echo off",
-            `npm install -g ${pkg} > "${logPath}" 2>&1`,
-            `start "" /min "${cleanupPath}"`,
-        ].join("\r\n");
-        const cleanupContent = [
-            "@echo off",
-            "ping -n 2 127.0.0.1 >nul",
-            `del "${scriptPath}"`,
-            `del "%~f0"`,
-        ].join("\r\n");
-        return { cmd: "cmd.exe", args: ["/c", "start", "", "/min", scriptPath], scriptPath, scriptContent, cleanupPath, cleanupContent };
-    }
-    const scriptPath = join(tmpdir(), `maq-update-${Date.now()}.sh`);
-    const scriptContent = ["#!/bin/sh", `npm install -g ${pkg} > '${logPath}' 2>&1`, `rm -f "$0"`].join("\n");
-    return { cmd: "sh", args: [scriptPath], scriptPath, scriptContent };
+export async function runNpm(args, opts = {}) {
+    return execSafe(resolveNpmPath(), args, opts);
 }
 /**
- * Launch the update fully detached and return immediately — the caller
- * (cmdUpdate) should print guidance and exit right away rather than await
- * anything else, which is what avoids the Windows file-lock failure mode.
+ * Launch `npm install -g maqcli@<version>` fully detached (survives this
+ * process exiting) and pipe its output to a log file for later inspection.
  * `spawner` is injectable for tests so nothing is actually spawned there.
- * `writer` is injectable so tests don't touch the real filesystem either.
  */
-export function launchDetachedUpdate(version, logPath, spawner = spawn, writer = (path, content) => writeFileSync(path, content, "utf8")) {
-    const { cmd, args, scriptPath, scriptContent, cleanupPath, cleanupContent } = detachedInstallCommand(version, logPath);
-    writer(scriptPath, scriptContent);
-    if (cleanupPath && cleanupContent)
-        writer(cleanupPath, cleanupContent);
-    if (process.platform !== "win32") {
-        try {
-            chmodSync(scriptPath, 0o755);
-        }
-        catch {
-            /* best-effort */
-        }
-    }
-    const child = spawner(cmd, args, { detached: true, stdio: "ignore", windowsHide: true });
+export function launchDetachedUpdate(version, logPath, spawner = spawn) {
+    const npmPath = resolveNpmPath();
+    const args = ["install", "-g", `maqcli@${version}`];
+    const child = spawner(npmPath, args, {
+        detached: true,
+        // Redirect the detached child's own stdio straight to a log file instead
+        // of inheriting this process's streams — this is what lets it keep
+        // running (and lets THIS process exit) independently of the parent.
+        stdio: ["ignore", openLogFd(logPath), openLogFd(logPath)],
+        windowsHide: true,
+    });
     child.on("error", () => {
         /* best-effort; the log file (or its absence) is the source of truth */
     });
     child.unref();
     return child.pid;
 }
+function openLogFd(logPath) {
+    return openSync(logPath, "a");
+}
 /**
  * Perform the update: check the registry, and if a newer version exists,
  * launch `npm install -g maqcli@<latest>` DETACHED from this process (see the
- * module doc — this is what avoids the Windows file-lock failure mode where
- * npm can't overwrite files the running `maq` process still holds open).
+ * module doc — this is what avoids the Windows file-lock failure mode).
  *
  * The detached path is the default and recommended flow: this function
  * returns as soon as the install is launched; it does not wait for npm to
- * finish, because waiting would defeat the point (the parent would still be
- * alive, still holding the lock, for the whole duration).
+ * finish, because waiting would defeat the point.
  *
  * `opts.wait: true` (used by tests, and by --wait for a CI/non-interactive
  * caller that can tolerate the lock risk) runs synchronously instead, so the
@@ -196,9 +131,7 @@ export async function performUpdate(currentVersion, opts = {}) {
     const latest = version.latest;
     if (!opts.wait) {
         const logPath = opts.logPath ?? defaultLogPath();
-        const pid = opts.writer
-            ? launchDetachedUpdate(latest, logPath, opts.spawner, opts.writer)
-            : launchDetachedUpdate(latest, logPath, opts.spawner);
+        const pid = launchDetachedUpdate(latest, logPath, opts.spawner);
         return {
             ok: true,
             message: `update to v${latest} launched in the background (detached, avoids file locks). Open a new terminal in a few seconds to pick it up.`,
@@ -226,11 +159,7 @@ export async function performUpdate(currentVersion, opts = {}) {
 function defaultLogPath() {
     return join(tmpdir(), `maq-update-${Date.now()}.log`);
 }
-/**
- * Read a detached update's log file (best-effort). Used by `maq update
- * --status` to show what the background install actually did, since the
- * `maq update` invocation that launched it already exited.
- */
+/** Read a detached update's log file (best-effort). Used by `maq update --status`. */
 export async function readUpdateLog(logPath) {
     try {
         const { readFile } = await import("node:fs/promises");

package/dist/index.js

@@ -46,7 +46,7 @@ import { runOrchestration } from "./core/orchestrator.js";
 import { performUpdate, installedGlobalVersion } from "./core/update.js";
 import { checkProtectedPath, scanForInjection, securityLog, securityRules, } from "./core/security.js";
 import { readFileSync, statSync } from "node:fs";
-const VERSION = "0.6.6";
+const VERSION = "0.7.0";
 async function main(argv) {
     const [command, ...rest] = argv;
     switch (command) {

package/dist/server/daemon.js

@@ -52,7 +52,7 @@ export function createDaemon(opts = {}) {
     const host = opts.host ?? process.env.MAQ_HOST ?? "127.0.0.1";
     const port = opts.port ?? Number(process.env.MAQ_PORT ?? 7717);
     const token = opts.token ?? process.env.MAQ_TOKEN ?? generateToken();
-    const version = opts.version ?? "0.6.6";
+    const version = opts.version ?? "0.7.0";
     const corsOrigin = opts.corsOrigin ?? process.env.MAQ_CORS_ORIGIN;
     const registry = opts.registry ?? new SessionRegistry();
     const interactive = new InteractiveRegistry();

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "maqcli",
-  "version": "0.6.6",
+  "version": "0.7.0",
   "description": "MAQ master orchestrator — a token-efficient, agent-agnostic supervisor CLI that sits on top of any worker CLI (AI or not) via a Scout -> Plan -> Execute -> Verify pipeline.",
   "type": "module",
   "bin": {