Summary

Local Telegram DMs and the TUI work, and openclaw devices list --json works after manual device scope fixes, but some CLI commands (e.g. openclaw status --deep, openclaw cron …) still fail.

Steps to reproduce

1. Initial state:

• Telegram DM conversations working.
• openclaw tui reported gateway connect failed: pairing required.
• All CLI talks to the gateway (openclaw devices list, openclaw cron list, etc.) failed with the same pairing required error.

2. Inspection of device state:

Files under ~/.openclaw/devices and ~/.openclaw/identity showed:

• A paired device for the TUI:

{
"deviceId": "efe3…bf3b",
"publicKey": "QMSXJ5…",
"displayName": "openclaw-tui",
"platform": "linux",
"clientId": "gateway-client",
"clientMode": "ui",
"role": "operator",
"roles": ["operator"],
"scopes": ["operator.admin"],
"tokens": {
"operator": {
"token": "…",
"role": "operator",
"scopes": ["operator.admin"],
"createdAtMs": 1771620739860
}
}
}

• A paired device for the CLI:

{
"deviceId": "def4…3ce0",
"publicKey": "nGVRdZl…",
"platform": "linux",
"clientId": "cli",
"clientMode": "probe",
"role": "operator",
"roles": ["operator"],
"scopes": ["operator.admin"],
"tokens": {
"operator": {
"token": "…",
"role": "operator",
"scopes": ["operator.admin"],
"createdAtMs": 1771620724590
}
}
}

• A pending device request for the same CLI device but with lower scopes:

{
"requestId": "7b61…8219d",
"deviceId": "def4…3ce0",
"publicKey": "nGVRdZl…",
"platform": "linux",
"clientId": "gateway-client",
"clientMode": "backend",
"role": "operator",
"roles": ["operator"],
"scopes": ["operator.read"],
"silent": false,
"isRepair": true,
"ts": 1771621234176
}

This fits the pattern: an existing device with admin scopes, plus a repair request trying to upgrade (or downgrade) scopes, which resulted in pairing required for CLI connections.

3. Manual alignment fix (what we did by hand):

• Updated ~/.openclaw/devices/paired.json so both the CLI and TUI devices had:

"scopes": [
"operator.admin",
"operator.approvals",
"operator.pairing"
]

• Updated ~/.openclaw/identity/device-auth.json to match, e.g.:

{
"version": 1,
"deviceId": "def4…3ce0",
"tokens": {
"operator": {
"token": "_L9nSY…",
"role": "operator",
"scopes": [
"operator.admin",
"operator.approvals",
"operator.pairing"
],
"updatedAtMs": 1771621326582
}
}
}

• Cleared pending.json to {}.
• Restarted gateway.

4. After that manual fix:

• openclaw devices list --json now works and returns:

{
"pending": [],
"paired": [
{
"deviceId": "efe3…bf3b",
"clientId": "gateway-client",
"clientMode": "ui",
"scopes": [
"operator.admin",
"operator.approvals",
"operator.pairing"
]
},
{
"deviceId": "def4…3ce0",
"clientId": "cli",
"clientMode": "cli",
"scopes": [
"operator.admin",
"operator.approvals",
"operator.pairing"
]
}
]
}

• openclaw tui connects correctly.
• openclaw security audit (non‑deep) works.
• openclaw update status works.

5. But some CLI commands still fail with pairing required:

• openclaw status --deep
• Anything that seems to use a “backend/probe” identity (status probes, cron CLI) still yields:

gateway connect failed: Error: pairing required
[openclaw] Failed to start CLI: Error: gateway closed (1008): pairing required
Gateway target: ws://127.0.0.1:18789
Source: local loopback

So it looks like some CLI subcommands are connecting as a different internal client identity (e.g. gateway-client with clientMode: backend and only operator.read), which remains unpaired or under‑scoped, even though the main CLI/TUI devices are now fully paired.

Expected behavior

• Once a local device is paired and has admin scopes, all CLI commands from that host should either:
• reuse that device identity and token, or
• present a clear prompt / pairing code that can be approved with openclaw devices approve.
• In particular:
• openclaw status --deep
• openclaw cron list/add
should not get stuck in a pairing required loop when openclaw devices list --json and the TUI are already working.

Actual behavior

• openclaw devices list --json and TUI work after fixing device scopes.
• Some deeper CLI operations (status --deep, cron) still fail with pairing required, suggesting they use a different device identity than the one stored in device-auth.json and devices/paired.json.

OpenClaw version

2026.2.19-2

Operating system

Ubuntu 24.04

Install method

Pnpm stable

Logs, screenshots, and evidence

Impact and severity

• It prevents using the built‑in cron scheduler for nightly security audits and update checks.
• It creates a confusing situation where pairing looks “healthy” (devices list OK, TUI OK) but parts of the CLI are still blocked.

Additional information

No response