Summary

The Control UI can continue to render an old /pair qr assistant card as a scannable QR after its setup/bootstrap token has expired. Users who scan that stale card in the mobile app are sent into the onboarding/auth flow only to receive Setup code expired.

Real environment observed

• OpenClaw Gateway / Control UI: 2026.6.11-beta.2
• Workflow: Control UI chat /pair qr, then scan the displayed QR from the iOS mobile app
• Gateway auth: token-protected LAN Gateway
• Mobile symptom: Setup code expired / The setup QR or bootstrap token is no longer valid.

User-visible symptom

A stale QR remains visually valid in the Control UI chat history. The user has no visible indication that the card should not be scanned anymore, so the mobile app appears broken even though the Gateway is correctly rejecting an expired bootstrap token.

Source-level repro on current main

1. Render an assistant message whose content includes an openclaw_pairing_qr block with image_url, alt, and an expiresAtMs timestamp in the past.
2. The Control UI still extracts the QR image_url into the renderable image list.
3. The stale QR is shown as a normal scannable image instead of being suppressed or marked expired.

Expected behavior

Expired pairing QR cards should not render as scannable QR images. The Control UI should make the stale state obvious and tell the user to run /pair qr again for a fresh setup code.

Actual behavior

The expired card still displays the QR image. Scanning it reaches the mobile app authentication step and fails with Setup code expired.

Scope / non-goals

• This is not a request to accept expired bootstrap tokens.
• This does not change Gateway authentication or mobile setup-code validation.
• The fix should only prevent stale Control UI QR cards from looking usable after expiration.

Proposed fix

Use the existing expiresAtMs field on openclaw_pairing_qr content blocks in the Control UI renderer: suppress expired QR images and render a small expired-state notice telling the user to run /pair qr again.