openclaw - 💡(How to fix) Fix macOS launchd Gateway still restarts via gateway-update/update.run; document and honor auto-update kill-switch

Summary

On macOS headless Gateway services managed by launchd, the Gateway can keep requesting full process restarts via the Gateway update path even when the Sparkle/UI updater is not the trigger. This makes the Gateway intermittently unavailable to control-plane health checks and plugin heartbeats.

Evidence

A live launchd-managed Gateway wrote this restart handoff file under the OpenClaw state directory:

{
  "kind": "gateway-supervisor-restart-handoff",
  "version": 1,
  "reason": "update.run",
  "source": "gateway-update",
  "restartKind": "update-process",
  "supervisorMode": "launchd"
}

The process then restarted under launchd. This is separate from Sparkle auto-update checks: disabling the Sparkle/defaults path reduced one trigger, but this gateway-update path still requested restarts.

Impact

For long-running/headless Gateway deployments, repeated update.run restarts cause recurring windows where HTTP/RPC health checks and plugin work become unreliable. In the same incident window, another already-filed pre-warm issue caused long event-loop stalls; this issue is specifically about the restart trigger/control path, not the provider auth pre-warm stall.

Related existing issue for the event-loop stall: #85999.

Expected behavior

Operators should have a documented, reliable way to disable Gateway package/background update restarts for supervised/headless deployments, preferably honoring OPENCLAW_NO_AUTO_UPDATE=1 in the launchd service environment before any gateway-update restart handoff is created.

Actual behavior

The launchd Gateway wrote a gateway-supervisor-restart-handoff.json with source=gateway-update, reason=update.run, and restartKind=update-process, then restarted the Gateway process.

Notes

The changelog mentions OPENCLAW_NO_AUTO_UPDATE=1 as a startup kill-switch for configured background package auto-updates, but this is hard to discover operationally and should be verified for the Gateway launchd path that writes the handoff file above.