Misleading log label for attempted-but-failed refresh

The warning always says "service env refresh skipped", but when attempted: true and ok: false (a candidate file was found, the command ran, and returned a non-zero exit code) the refresh was not skipped — it was attempted and failed. The word "skipped" only accurately describes the cases where the service is not installed (ok: true) or the command was never invoked (service check threw, or no candidate file existed).

Consider branching on refreshResult.attempted to distinguish the two situations:

if (!refreshResult.ok) {
  const verb = refreshResult.attempted ? "failed" : "skipped";
  context?.logGateway?.warn(
    `update.run service env refresh ${verb} ${formatControlPlaneActor(actor)} reason=${refreshResult.reason ?? "unknown"}`,
  );
}

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

Comment:
**Misleading log label for attempted-but-failed refresh**

The warning always says `"service env refresh skipped"`, but when `attempted: true` and `ok: false` (a candidate file was found, the command ran, and returned a non-zero exit code) the refresh was not skipped — it was attempted and failed. The word "skipped" only accurately describes the cases where the service is not installed (`ok: true`) or the command was never invoked (service check threw, or no candidate file existed).

Consider branching on `refreshResult.attempted` to distinguish the two situations:

```typescript
if (!refreshResult.ok) {
  const verb = refreshResult.attempted ? "failed" : "skipped";
  context?.logGateway?.warn(
    `update.run service env refresh ${verb} ${formatControlPlaneActor(actor)} reason=${refreshResult.reason ?? "unknown"}`,
  );
}
```

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

stderr omitted from failure reason

When runCommandWithTimeout returns a non-zero exit code, res.stderr is available but not captured in the reason string. Since this reason flows directly into the warning log, any error message printed by openclaw.mjs gateway install will be silently discarded, making production failures harder to diagnose.

    return {
      attempted: true,
      ok: false,
      reason: `refresh failed (${candidate}): exit=${res.code}${res.stderr ? ` stderr=${res.stderr.trim()}` : ""}`,
    };

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

Comment:
**`stderr` omitted from failure reason**

When `runCommandWithTimeout` returns a non-zero exit code, `res.stderr` is available but not captured in the `reason` string. Since this `reason` flows directly into the warning log, any error message printed by `openclaw.mjs gateway install` will be silently discarded, making production failures harder to diagnose.

```typescript
    return {
      attempted: true,
      ok: false,
      reason: `refresh failed (${candidate}): exit=${res.code}${res.stderr ? ` stderr=${res.stderr.trim()}` : ""}`,
    };
```

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

Avoid self-restarting gateway while handling update.run

The refresh command now runs gateway install --force (src/gateway/server-methods/update.ts), but that install path actively restarts the service (src/daemon/systemd.ts:262 calls systemctl --user restart, and src/daemon/launchd.ts:411 bootouts/reloads the LaunchAgent). Because this refresh runs before sentinel writing and before the explicit SIGUSR1 scheduling, calling update.run from the daemonized gateway process can terminate the in-flight handler, which can drop the response/sentinel and bypass the controlled restart flow.

Useful? React with 👍 / 👎.

Catch unsupported service resolution in env refresh path

refreshGatewayServiceEnvFromUpdatedInstall calls resolveGatewayService() outside any try/catch, but resolveGatewayService throws on unsupported platforms (src/daemon/service.ts). That means a successful runGatewayUpdate can now be turned into an unhandled error in update.run on those platforms, which is a regression from the previous behavior where the handler always continued to build and return the update payload.

Useful? React with 👍 / 👎.

Catch service-refresh spawn failures in update.run

refreshGatewayServiceEnvFromUpdatedInstall treats non-zero exits as recoverable, but the runCommandWithTimeout(...) call can also reject on child-process startup errors (see src/process/exec.ts where child.on("error") rejects). In environments where the refresh command cannot be spawned (for example missing node when the gateway runtime is Bun, or ENOENT/EACCES for the resolved entrypoint), this throws out of update.run after a successful update, so the handler can return an UNAVAILABLE error instead of writing the restart sentinel and scheduling the controlled restart.

Useful? React with 👍 / 👎.