Math.max(undefined, 2000) evaluates to NaN, causing immediate exit

restartDelayMs has type number | undefined (see parseRestartRequestParams). When the caller omits this parameter, restartDelayMs is undefined, and Math.max(undefined, 2000) returns NaN in JavaScript. setTimeout(fn, NaN) treats NaN as 0, so process.exit(0) fires on the very next event-loop tick — before the WebSocket / HTTP response written by respond() above has had a chance to flush. The client never receives the "detached" response and the update appears to have silently failed.

This is a comment left during a code review.
Path: src/gateway/server-methods/update.ts
Line: 119

Comment:
**`Math.max(undefined, 2000)` evaluates to `NaN`, causing immediate exit**

`restartDelayMs` has type `number | undefined` (see `parseRestartRequestParams`). When the caller omits this parameter, `restartDelayMs` is `undefined`, and `Math.max(undefined, 2000)` returns `NaN` in JavaScript. `setTimeout(fn, NaN)` treats `NaN` as `0`, so `process.exit(0)` fires on the very next event-loop tick — before the WebSocket / HTTP response written by `respond()` above has had a chance to flush. The client never receives the "detached" response and the update appears to have silently failed.

```suggestion
      }, Math.max(restartDelayMs ?? 0, 2000));
```

How can I resolve this? If you propose a fix, please make it concise.

readDetachedUpdateResult is exported but never consumed

The detached helper writes a JSON result file (e.g. {"ok":false,"reason":"install-failed","exitCode":1}) so the next Gateway boot can surface the outcome to the user. However, nothing in this PR reads that file on startup. The diagnostic information is silently discarded: a failed update leaves no visible signal in the UI, logs, or restart sentinel.

Consider wiring up a startup check (e.g. in the Gateway boot sequence) that calls readDetachedUpdateResult for any pending result path — perhaps stored in the restart sentinel written in update.ts at line 90 — and then emits a log warning or an observable update-status event before deleting the result file.

This is a comment left during a code review.
Path: src/infra/update-detached-win32.ts
Line: 178-188

Comment:
**`readDetachedUpdateResult` is exported but never consumed**

The detached helper writes a JSON result file (e.g. `{"ok":false,"reason":"install-failed","exitCode":1}`) so the next Gateway boot can surface the outcome to the user. However, nothing in this PR reads that file on startup. The diagnostic information is silently discarded: a failed update leaves no visible signal in the UI, logs, or restart sentinel.

Consider wiring up a startup check (e.g. in the Gateway boot sequence) that calls `readDetachedUpdateResult` for any pending result path — perhaps stored in the restart sentinel written in `update.ts` at line 90 — and then emits a log warning or an observable update-status event before deleting the result file.

How can I resolve this? If you propose a fix, please make it concise.

Propagate prepared env to detached updater process

This detached path drops the install environment assembled in runGatewayUpdate: spawnDetachedUpdate accepts env but never passes it to spawn(...), so the helper runs with the parent process environment instead of globalInstallEnv. On Windows, that loses values from createGlobalInstallEnv (notably portable-Git PATH prepends and npm config vars), which can make detached npm i -g fail on machines that rely on those settings even though the previous in-process update path succeeded.

Useful? React with 👍 / 👎.

Clamp detached shutdown delay to helper wait window

The gateway exit delay is taken from restartDelayMs without an upper bound, but the detached helper only waits 60 seconds for this PID before aborting with pid-wait-timeout. If a caller sends restartDelayMs > 60000, the helper exits before the gateway stops, so the install/restart never runs and the later process.exit(0) can leave the gateway down.

Useful? React with 👍 / 👎.

Default detached exit delay to a finite value

restartDelayMs is optional, but this call computes Math.max(restartDelayMs, 2000) directly; when the caller omits restartDelayMs, that expression becomes NaN, and Node timers treat NaN like an immediate timeout. In the detached update path this can call process.exit(0) almost instantly, which can cut off the update.run response before it flushes to the client in the common default-parameter case.

Useful? React with 👍 / 👎.

Preserve npm omit-optional retry in win32 detached updates

The Windows branch delegates a single globalInstallArgs(...) command to the helper and returns early, so it never reaches the existing npm fallback retry (globalInstallFallbackArgs) used elsewhere in this function. That regresses environments where the first global npm install fails but the --omit=optional retry succeeds, causing Windows updates to fail in cases that were previously handled.

Useful? React with 👍 / 👎.

Escape detached install argv for cmd metacharacters

This constructs installCommand by only wrapping args that contain spaces, but cmd.exe still interprets metacharacters like &, |, %, !, and ^ in unescaped arguments. In the detached path, package specs such as signed URLs or local paths containing these characters can be split/expanded and make the update command fail (or execute unintended fragments), whereas the previous in-process argv execution avoided shell parsing.

Useful? React with 👍 / 👎.

Report delegated update as pending until install actually finishes

The win32 global-update path returns status: "ok" as soon as the detached helper is spawned, before any install step runs. update.run then uses that status for the API response and restart sentinel, so if the helper later records install-failed or pid-wait-timeout, users still get a success-style restart message on next boot. This masks real update failures and regresses observability versus the previous synchronous path; the delegated flow should not be marked ok until detachedResultPath has been reconciled.

Useful? React with 👍 / 👎.

Require supervised restart capability before forced detached exit

This branch unconditionally hard-exits the gateway after delegation, but the helper restart mechanism is schtasks-only and no check is performed that the current Windows runtime is actually task-supervised. In unsupervised runs (which the existing restart pipeline explicitly supports via in-process fallback), the helper cannot relaunch the process, so update.run can leave the gateway down immediately after returning success. Gate detached exit behind detected scheduled-task supervision, or keep the prior restart fallback path.

Useful? React with 👍 / 👎.