OpenClaw Gateway Connection Failures Now Surface Immediately

Debugging OpenClaw Gateway connection failures just got a lot less frustrating. A focused fix merged today (PR #85253) makes local connect assembly errors surface immediately instead of leaving CLI commands hanging until they time out.

The Bug

When the OpenClaw Gateway received a connect.challenge message, it assembled device identity parameters inside a broad try/catch in handleMessage. If anything went wrong during local signing — malformed identity key material, a bad PEM, or any assembly-time error — the exception was swallowed, logged as a generic "gateway client parse error," and the command sat waiting for the wrapper timeout to fire.

From the user's perspective: you run an openclaw CLI command, it stalls with no indication of what's wrong, and eventually fails with a timeout. The real cause — a misconfigured device identity or corrupted cert — was invisible.

The Fix

PR #85253 by @samzong restructures the connect flow to fail fast on local assembly errors:

• Assembly happens before the connectSent flag is set. Connect parameter assembly is now moved earlier in the flow, before watchdog mutations or state changes occur.
• Assembly failures propagate through onConnectError. When local signing throws, the failure is marked internally and surfaced through callGateway immediately — no waiting for wrapper timeout.
• Scope is narrow. Server rejection, socket close, and challenge-timeout behavior are all unchanged. Only internally-generated assembly failures become terminal.

In the fix author's own testing, a malformed device identity now resolves in approximately 40ms rather than waiting out the full connection timeout. The PR includes terminal output from a real local WebSocket Gateway session showing the 40ms fast-fail path.

Regression Tests

The fix ships with four focused regression tests covering:

• Immediate callGateway rejection on connect errors
• No connect frame sent after bad identity assembly
• Contained event callback errors
• Contained onConnectError callback throws

These tests protect the behavior going forward so the swallowed-error pattern doesn't regress silently.

Who This Affects

Anyone using the OpenClaw CLI against a Gateway with device identity configured — which covers most production and self-hosted setups. If you've ever been puzzled by a CLI command that stalls on connection and eventually dies with a vague timeout error, this fix is directly relevant.

The change is in main now and will land in the next tagged v2026.5.x release.