openclaw - 💡(How to fix) Fix TUI requires scope re-approval after reboot despite valid tokens in paired.json [1 pull requests]

Summary

After rebooting the machine, the OpenClaw TUI requires full scope re-approval even though valid tokens and approvals exist in paired.json. This forces users to manually approve scope upgrades every restart.

Steps to Reproduce

1. Pair TUI device and approve scopes (admin, pairing, write)
2. Reboot machine
3. Start openclaw tui
4. Observe: "Pairing required" with "scope upgrade, repair" status
5. Device shows as pending approval even though it was already approved

Expected Behavior

TUI should load stored tokens from paired.json and connect without requiring re-approval. Device fingerprint and approval state should persist across reboots.

Actual Behavior

TUI triggers a new scope upgrade/repair request after every reboot, requiring manual approval via openclaw devices approve <requestId>.

Evidence

Device fingerprint IS stable across requests:

• Multiple pending requests showed same fingerprint: 84150d7f9e8e05e16c4609048bfab5c395d8344e50bf5e8b9247e3da0e78e862
• Fingerprint in paired.json matches: 84150d...
• Device is marked as paired with scopes: operator.read, operator.pairing, operator.admin

But TUI directory lacks persistent device key:

~/.openclaw/tui/
total 12
drwx------ 2 chris chris 4096 May 10 21:23 .
drwx------ 29 chris chris 4096 May 10 23:11 ..
-rw------- 1 chris chris 229 May 11 10:27 last-session.json
(no device.json)

CLI has separate device identity that persists:

~/.openclaw/device.json
{
  "version": 1,
  "deviceId": "cabc0570f37214b52b4e2515b18b732829f14be7dfffc5bcd5eb082cf16fa3c5",
  ...
}

paired.json shows valid tokens exist:

{
  "84150d...": {
    "scopes": ["operator.read", "operator.pairing", "operator.admin"],
    "tokens": {
      "operator": {
        "scopes": ["operator.admin", "operator.read", "operator.write"],
        ...
      }
    }
  }
}

Hypothesis

The TUI fingerprint appears stable (same across pending requests), suggesting it's derived from system-level identifiers rather than a stored file. The bug is likely in token loading on startup — stored tokens in paired.json aren't being properly loaded/validated after reboot, triggering unnecessary "repair" requests.

Environment

• OpenClaw version: 2026.5.7 (eeef486)
• Platform: Linux (Ubuntu/Debian)
• Gateway: systemd user service, port 18789 (loopback)