Observed

In a fresh-ish OpenClaw deployment (running `2026.5.2`), `~/.openclaw/devices/paired.json` shows every entry with `createdAt: null` and `lastSeenAt: null`:

```json
[
{ "clientId": "cli", "role": "operator", "createdAt": null, "lastSeenAt": null },
{ "clientId": "gateway-client", "role": "operator", "createdAt": null, "lastSeenAt": null },
... (9 more gateway-client entries, all null)
]
```

Why this matters operationally

Without timestamps, an operator cannot tell stale devices apart from active ones. Standard hygiene (revoke devices not seen in N days) is impossible. The file accumulates entries indefinitely.

Expected

`createdAt` populated on first pair; `lastSeenAt` updated on each accepted authentication (or on a periodic basis if precise per-request tracking is too costly).

Workaround

We've started maintaining a manual log alongside `paired.json` (`docs/openclaw/paired-devices-log.md` in our repo) — every pairing requires the operator to append a one-line entry. Brittle (relies on operator discipline) but produces a usable audit trail until this is fixed upstream.

Environment

• OpenClaw `2026.5.2` (Linux x86, Docker image `ghcr.io/openclaw/openclaw`)
• 10 paired entries accumulated over months of operation
• Pairing flow used: standard `openclaw` CLI pairing + gateway-sidecar startup pairing

Happy to capture more diagnostic info if helpful.