return false is dead code and inconsistent with the rest of runServiceStart

fail() calls defaultRuntime.exit(1) which terminates the process in production, so return false on line 207 is never reached at runtime. In tests, exit throws, so again return false is unreachable. All other early-exit paths in runServiceStart use a bare return (returning undefined), and the function has no declared return type. The return false looks like an accidental copy-paste from runServiceRestart, which has an explicit Promise<boolean> return type.

This is a comment left during a code review.
Path: src/cli/daemon-cli/lifecycle-core.ts
Line: 203-208

Comment:
**`return false` is dead code and inconsistent with the rest of `runServiceStart`**

`fail()` calls `defaultRuntime.exit(1)` which terminates the process in production, so `return false` on line 207 is never reached at runtime. In tests, `exit` throws, so again `return false` is unreachable. All other early-exit paths in `runServiceStart` use a bare `return` (returning `undefined`), and the function has no declared return type. The `return false` looks like an accidental copy-paste from `runServiceRestart`, which has an explicit `Promise<boolean>` return type.

```suggestion
      fail(
        `${params.serviceNoun} aborted: config is invalid.\n${configError}\nFix the config and retry, or run "openclaw doctor" to repair.`,
      );
      return;
```

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

Stack trace dropped from crash-guard error log

Only err.message is captured in the logged string. If startup fails due to an unexpected internal error (not just a config issue), the stack trace is silently discarded, making it harder to diagnose the root cause. Consider including the full stack when available:

(only if gatewayLog.error accepts a second cause argument — otherwise logging err.stack inline is an equivalent alternative)

This is a comment left during a code review.
Path: src/cli/gateway-cli/run-loop.ts
Line: 193-203

Comment:
**Stack trace dropped from crash-guard error log**

Only `err.message` is captured in the logged string. If startup fails due to an unexpected internal error (not just a config issue), the stack trace is silently discarded, making it harder to diagnose the root cause. Consider including the full stack when available:

```suggestion
        server = null;
        gatewayLog.error(
          `gateway startup failed: ${err instanceof Error ? err.message : String(err)}. ` +
            "Process will stay alive; fix the issue and restart.",
          err instanceof Error ? err : undefined,
        );
```

_(only if `gatewayLog.error` accepts a second cause argument — otherwise logging `err.stack` inline is an equivalent alternative)_

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

Validate config using service env before aborting start/restart

This pre-flight check reads config with readConfigFileSnapshot() against the current CLI environment, so configs that intentionally use ${ENV_VAR} values provided only by launchd/systemd are treated as invalid and gateway/node daemon start|restart are aborted. readConfigFileSnapshot marks missing env substitutions as invalid (see src/config/io.ts around env-substitution failure handling), so operators can no longer restart a healthy service unless they also export all runtime secrets in their shell. That is a regression from previous behavior and should use the service runtime env (or ignore substitution-only failures) before blocking.

Useful? React with 👍 / 👎.

Re-throw initial gateway startup failures

Catching all params.start() exceptions here prevents startup failures from ever reaching runGatewayCommand's outer try/catch (src/cli/gateway-cli/run.ts), which is what reports "Gateway failed to start" and exits non-zero. After this change, an initial bind/auth/config failure leaves the process alive but not serving (and still holding the gateway lock) until a manual restart signal, so supervised deployments can get stuck in a permanently "running but dead" state instead of failing fast and recovering.

Useful? React with 👍 / 👎.

Use daemon env for pre-flight config snapshot

getConfigValidationError() validates via readConfigFileSnapshot() using the current CLI environment, but gateway start/restart acts on the installed service, which may run with a different OPENCLAW_STATE_DIR/OPENCLAW_CONFIG_PATH and env substitutions from its persisted service environment. In that mismatch case, this guard can validate the wrong file (allowing a restart that still crashes) or block a healthy restart because only the shell config is invalid, so the regression this patch is trying to prevent remains in multi-profile/service-env setups.

Useful? React with 👍 / 👎.

Validate config before signaling unmanaged restart

runServiceRestart performs the new pre-flight config check only after onNotLoaded has already run, but the gateway caller’s onNotLoaded path (runDaemonRestart → restartGatewayWithoutServiceManager) sends SIGUSR1 immediately to the unmanaged process; with an invalid config, this means the restart is triggered before we fail with "aborted: config is invalid," so the guard does not actually prevent the risky restart in that flow and can report a misleading abort after side effects have already happened.

Useful? React with 👍 / 👎.

Validate restart config with service environment

getConfigValidationError() reads readConfigFileSnapshot() from the current CLI environment, but runServiceStart/runServiceRestart operate on a service that may have different persisted env (notably OPENCLAW_STATE_DIR, OPENCLAW_CONFIG_PATH, and service-only substitutions), so this check can both block healthy restarts and miss invalid service-side configs that still crash after restart. Fresh evidence in this commit is the new function comment explicitly stating validation is done in the CLI environment.

Useful? React with 👍 / 👎.

Avoid trapping restart failures in non-listening loop state

After the first successful boot, this branch swallows params.start() failures and keeps the process alive with server = null; in unmanaged/in-process restart mode (for example OPENCLAW_NO_RESPAWN=1 or respawn fallback), daemon restart/stop can only signal PIDs discovered from listeners on the gateway port (restartGatewayWithoutServiceManager), so a failed restart before bind leaves no signalable PID while the process still holds the gateway lock, forcing manual process cleanup.

Useful? React with 👍 / 👎.

Reacquire lock before retrying a failed in-process restart

Calling releaseLockIfHeld() in the restart-failure catch path drops the gateway lock, but later restart attempts only reacquire when handleRestartAfterServerClose() sees hadLock === true. In OPENCLAW_NO_RESPAWN=1 (or respawn failed) mode, a second SIGUSR1 after this failure will restart the loop without reacquiring the lock, so the gateway can come back up lockless and allow duplicate/coordinated-management breakage across processes.

Useful? React with 👍 / 👎.