Summary

When the gateway starts with gateway.tailscale.mode: "serve", the startup sequence runs several tailscale commands in rapid succession:

1. findTailscaleBinary(): which tailscale → tailscale --version (binary verification)
2. enableTailscaleServe(): tailscale serve --bg --yes <port>
3. getTailnetHostname(): tailscale status --json

Under any system load (e.g., during a gateway restart, or when openclaw status is called), step 3 transiently fails with a non-zero exit code, logged as Command failed: tailscale status --json (visible because verbose/debug logging is enabled).

Environment

• macOS (arm64), launchd-managed gateway service
• Tailscale via Homebrew (/opt/homebrew/bin/tailscale, v1.94.1)
• Daemon socket: /var/run/tailscaled.socket (permissions: srw-rw-rw-)
• gateway.tailscale.mode: "serve"

Reproduction

Occurs reliably on every gateway restart. The sequence works fine in isolation — the failure is specific to the rapid back-to-back execution during startup under load.

Impact

• The error is caught (startGatewayTailscaleExposure wraps in try/catch), so the gateway continues to function
• Tailscale serve still gets configured correctly in most cases
• The logged error causes user confusion — it looks like a real failure

Suggested Fix

Add a small retry/backoff between enableTailscaleServe and getTailnetHostname, or retry readTailscaleStatusJson on transient failures. A 1-2 retry with a short delay (e.g. 500ms) would eliminate the race without meaningfully slowing startup.

Alternatively, expose a config option for the tailscale binary path (e.g. gateway.tailscale.binaryPath) so users on non-standard setups can skip the discovery chain entirely.