Environment

• OpenClaw: 2026.4.29 (a448042)
• Node.js: 22.22.2
• OS: Linux (Ubuntu/Debian)
• Gateway mode: local systemd service (openclaw-gateway.service)

Summary

In v29, running any openclaw CLI command (e.g. openclaw health --json, openclaw cron list --json, openclaw tasks list) causes the running systemd-managed gateway to restart. This results in:

• ~15–20s of Telegram channel downtime per CLI invocation
• Gateway restart loop when multiple CLI commands run in quick succession
• System-wide performance degradation if any tool/dashboard repeatedly calls CLI subprocesses

Root cause (observed)

v29 introduced a new startup behavior visible in the gateway log:

[gateway] already running under systemd; waiting 5000ms before retrying startup

Previously (pre-v29), a CLI-spawned process that detected a running gateway would exit immediately with code 78 to prevent restart loops. In v29, the process waits 5 seconds and retries, apparently taking over the port from the running instance and causing the existing gateway to shut down.

Steps to reproduce

1. Start openclaw-gateway.service (systemd, Restart=always)
2. Wait for gateway to fully start (Telegram connected, health OK)
3. Run: openclaw health --json
4. Observe gateway-service.log: within ~20s, a new starting HTTP server... entry appears
5. Telegram bot disconnects briefly and reconnects

Impact

• Any monitoring dashboard that calls openclaw CLI subprocesses to poll status causes continuous gateway restarts
• Telegram channel drops and reconnects on every CLI invocation
• Before this was identified, a dashboard refreshing every 30s (with 4 CLI calls) was causing the gateway to restart every ~7 seconds

Expected behavior

CLI commands should connect to the existing gateway via WebSocket without triggering a gateway port takeover. The pre-v29 behavior (exit immediately with code 78 when gateway is healthy) was correct.

Workaround

Avoid running openclaw CLI commands while the gateway is running. Use the gateway's WebSocket/HTTP API directly instead of CLI subprocesses for monitoring.

Additional context

Also observed in this update:

• Gateway crash loop on first start after v29 update due to SECRETS_RELOADER_DEGRADED: OPENCLAW_GATEWAY_TOKEN missing (required a manual env file update — breaking change not documented)
• vault-sync cron with sessionTarget: isolated failing with CodexAppServerRpcError: failed to load configuration: Model provider 'openrouter' not found when Anthropic provider is unavailable and fallback reaches Codex