Summary

On macOS, when gateway auth token changes (or is regenerated) during config rewrites/restarts, OpenClaw.app can enter a reconnect loop with alternating errors:

• unauthorized: gateway token mismatch
• pairing required
• intermittent Could not connect to the server during restart windows

This creates sustained log spam and makes the node appear broken even after approvals.

Environment

• Gateway CLI: openclaw 2026.3.9
• macOS app observed: 2026.3.8-beta.1
• Local gateway: ws://127.0.0.1:18789

Observed log signals

• Gateway out:
  • auth token was missing. Generated a new token and saved it to config (gateway.auth.token).
  • frequent SIGTERM/restart cycles
• Gateway/App:
  • unauthorized ... reason=token_mismatch
  • closed before connect ... code=1008 reason=pairing required
  • Could not connect to the server during restart windows

Repro (approx)

1. macOS app connected locally to gateway (127.0.0.1:18789).
2. Trigger config writes touching auth/restart path.
3. Gateway rotates/regenerates auth token and restarts.
4. App/node attempts reconnect with stale auth/device role state.
5. Loop: token mismatch + pairing required + connect failures.

Expected

• Token/auth state should remain stable across benign config writes/restarts, or
• clients should re-handshake cleanly once token changes, without prolonged spam loops.

Actual

• repeated auth/pairing/connect failures until manual repair/reset/pairing/token rotation.

Temporary mitigation that helped

• re-approve pending node pairing request
• rotate node token
• stabilize gateway (avoid further auth-token churn/restarts)

Suggested fixes

1. Prevent silent auth token regeneration unless explicitly requested.
2. If token changes, surface a single clear state transition to clients and suppress reconnect spam.
3. Make node-role upgrade flow (operator -> node) resilient to concurrent restart/auth transitions.
4. Consider backoff/jitter + deduplicated error emission in app logs for this class.