Bug

The OpenClaw iOS app (v2026.6.10, iOS 26.5.1, iPhone18,1) fails to persist its device auth token across app close/reopen cycles. Each time the app reconnects to the gateway, it triggers a new permission re-approval request instead of presenting its existing approved device token.

Environment

• Gateway: OpenClaw 2026.6.10, running on Linux (Ubuntu, kernel 6.8.0-124-generic), gateway.bind=lan, ws:// (no TLS, VPN-encrypted LAN)
• Gateway auth mode: token (1Password SecretRef exec provider)
• iOS app: v2026.6.10, installed from App Store
• Device: iPhone18,1, iOS 26.5.1
• Network: iPhone connects via VPN to LAN

Reproduction

1. Pair iPhone via QR code (openclaw qr) or manual setup (host + port + token)
2. Approve the node pairing on the gateway: openclaw nodes approve <requestId>
3. App connects successfully — openclaw nodes status shows paired · connected · approved
4. Close the app (background or force-close)
5. Reopen the app
6. App reconnects but gateway shows: paired · connected · reapproval pending
7. openclaw nodes approve <new requestId> is required every time

Expected behavior

The app should persist its device token (keychain) and present it on reconnect. The gateway should recognize the already-approved device and resume the session without requiring manual re-approval.

Actual behavior

The app appears to lose or not send its device token on reconnect, triggering a fresh permission escalation request each time. The gateway-side pairing record persists correctly (device shows as "paired" in openclaw devices list), but the node connection keeps requesting new approvals.

Additional notes

• The QR bootstrap flow also exhibited a related issue: AUTH_TOKEN_MISSING error on reconnect after app close, suggesting the bootstrap token is not being persisted either
• Manual setup (entering host/port/token directly) connects successfully but still hits the re-approval loop on reconnect
• Other platforms (Windows node, pi5-test node) do not exhibit this behavior — they reconnect without re-approval
• Gateway logs show the device reconnecting from the same IP with the same node ID, so it's not a duplicate-device issue

Workaround

Manual openclaw nodes approve <requestId> on each reconnect, or gateway.nodes.pairing.autoApproveCidrs scoped to the VPN subnet (not ideal for security-conscious setups).