OpenClaw's mobile pairing flow just received a practical reliability fix for one of the most frustrating setup states: trying to connect Android or iOS to a gateway the phone cannot actually reach.
The change landed in PR #142651, titled fix(mobile): show failures and recovery for unreachable gateways. The issue was straightforward but painful. When a gateway was offline, unreachable through Tailscale, or stuck before TLS completed, the mobile app could leave users staring at Connecting or show an error without a useful next step.
That matters because OpenClaw mobile setup is not just a login form. It is pairing a phone with a machine that may live on a LAN, a tailnet, or a remote network path. A failure should tell users whether they can retry the same target, review network access, or restart setup without losing the original security context.
What Changed
The PR gives Android connection attempts explicit ownership over their preflight, transport, and cleanup deadlines. If an attempt is canceled or superseded, stale callbacks cannot come back later and overwrite the current target with old state.
On iOS, preflight failures now use the existing typed problem presentation. Retry keeps the failed target and unconsumed setup intent instead of silently falling back to a previously saved gateway.
The user-facing result is cleaner:
- Unreachable gateway attempts now produce an actionable failure state.
- Retry remains separate from broader setup recovery.
- Tailscale guidance appears when relevant without claiming the VPN is definitely off or required.
- Certificate trust, setup fingerprints, credentials, and pairing approval remain separate.
That last point is important. The PR description explicitly says it does not relax TLS or authentication, change VPN settings, add configuration, or increase existing iOS timeout budgets. This is about making the failure visible and recoverable, not weakening the pairing boundary.
Why It Matters
Good setup UX is security work. When an app hides the real failure behind a spinner, users start guessing. They may reset the wrong thing, paste new credentials, or abandon a valid setup link because the interface never explained what went wrong.
OpenClaw's fix keeps the failed target attached to the retry path. That means the app can say, in effect: this gateway is the one that failed, these constraints still apply, and this is the action that tries it again.
For Tailscale users, this is especially useful. A .ts.net address can fail because the gateway is asleep, the phone is outside the tailnet, DNS cannot resolve the name, or TLS never completes. The app now has a better path to show the problem without confusing network reachability with trust acceptance.
Validation
The PR reports exact-head CI passing with 88 successful jobs, 11 intentional skips, and zero failures or cancellations. Focused Android and iOS validation passed, along with the full macOS test lane and localization checks.
The mobile evidence is concrete: Android unit tests covered gateway TLS, endpoint handling, reconnect behavior, socket publication, bootstrap auth, and onboarding logic. iOS tests covered connection controllers, reconnect error retention, security, setup link staging, QR completion, pending target suppression, and SwiftUI smoke paths.
The maintainers also published screenshots showing Android and iOS unreachable-gateway states with visible retry and recovery actions. Those images were described as repaired-app captures rather than reconstructed before-and-after screenshots, which is the right level of claim for a merged reliability fix.
For users, this should make first-run mobile pairing feel less like a dead end. For operators, it reduces one more class of ambiguous support report: "the app is stuck connecting" becomes a specific, recoverable gateway failure.