Summary

On iOS, QR pairing can appear successful, but the mobile chat/Control UI remains unusable: the app shows the gateway as connected during/after QR setup, then the chat view reports disconnected, and returning to the app can lose the stored Gateway Token, forcing the onboarding/token flow to loop. Safari on the same phone also fails to keep/use the Control UI session reliably.

This looks related to the recent iOS LAN/setup-code/operator-token fixes, but it is still reproducible with the current gateway and the currently available iOS app build.

Environment

• Gateway/CLI: OpenClaw 2026.6.11-beta.2 (4f9d586)
• iOS app/node: openclaw-ios/node, ui v2026.6.10
• Device: iPhone16,2, iOS 26.5.0
• Gateway bind: lan
• Gateway auth mode: token
• Tailscale mode: off
• Dashboard: LAN HTTP, http://192.168.1.120:18789/
• gateway.controlUi.allowInsecureAuth=true
• gateway.controlUi.dangerouslyDisableDeviceAuth=true

No gateway auth token is included here.

Observed behavior

1. Generate/scan QR code for the gateway from the iPhone app.
2. The phone initially reports connected / pairing appears to succeed.
3. From the gateway CLI, the iPhone can appear as approved/paired, and at least once device.status worked successfully.
4. Opening the chat inside the iOS app reports disconnected.
5. Returning to the app can lose the stored Gateway Token, sending the user back through the token/onboarding loop.
6. Safari on the same iPhone also fails to use the dashboard/chat reliably.
7. After the loop, the node may show as approved but disconnected:

Name     iPhone
Client   openclaw-ios/node
IP       192.168.1.103
Device   iPhone
Model    iPhone16,2
Version  ui v2026.6.10
Status   paired · disconnected
Approval approved

Trying to invoke the node after that fails with:

nodes invoke failed: GatewayClientRequestError: node not connected

Gateway itself is running and reachable locally:

Gateway version: 2026.6.11-beta.2
Runtime: running
Connectivity probe: ok
Capability: admin-capable
Listening: *:18789

Expected behavior

After QR pairing on iOS, the app should persist the correct gateway/operator token, the node should remain connected, and the in-app chat/Control UI should be usable without re-entering the Gateway Token.

Related work

This appears adjacent to, or a regression around, the same auth/onboarding class as:

• fix: repair iOS LAN pairing #78201 - iOS LAN pairing / stale bootstrap handling
• [codex] restore QR bootstrap operator handoff #83684 - restore QR bootstrap operator handoff / stale gateway token reset suggestion
• fix(auth): operator scope mismatch silently rejected as device token mismatch #79292 - operator scope mismatch presented as token mismatch / reconnect loop
• fix(gateway): gate talk secret bootstrap handoff #85690 - talk secret bootstrap handoff
• [Bug]: UI chat not opening #45471 - Control UI chat/token mismatch symptoms

Notes

The gateway-side pairing is not completely broken: the iPhone has been seen as paired/approved and node commands worked briefly. The failure appears to be specifically the mobile app/Safari Control UI operator session or token persistence path after pairing, especially on plain LAN HTTP without Tailscale/HTTPS.

There is currently no newer iOS app update available to the user, so if the fix requires an app release newer than ui v2026.6.10, the currently shipped iOS build is effectively non-functional for mobile chat over this setup.