OpenClaw Cron Pairing And Operator Scopes
中文 | English
Summary
Cron creation can fail even when the gateway is up and the machine looks otherwise healthy. In one real OpenClaw setup, the actual problem was not cron itself but insufficient paired-device operator scopes, which caused the gateway to reject cron operations with a pairing-flavored close reason.
Symptom
Cron operations such as cron(action="status") or job creation failed with:
gateway closed (1008): pairing requiredThis was easy to misread as an incomplete pairing flow or a broken cron subsystem.
Root Cause
The failure was caused by an operator-scope mismatch on the runtime identity that actually talked to the gateway. The machine already had pairing data, but the effective client was gateway-client, and its granted scopes were too narrow for cron actions. That made the gateway reject the request with a pairing-flavored close reason even though pairing had already happened.
A second trap was that updating only the paired-device record was not enough in this setup. The runtime also carried its own local auth view in identity/device-auth.json, so the effective scopes could still stay stale after paired.json was edited.
How To Confirm
- Inspect
~/.openclaw/identity/device.jsonto identify the runtime device and client actually used by the local OpenClaw process. - Inspect
~/.openclaw/identity/device-auth.jsonto see the scopes currently attached to that runtime identity. - Inspect
~/.openclaw/devices/paired.jsonand confirm the matching paired-device record for the same device or client. - Verify whether the runtime identity is
gateway-clientor some other client instead of assuming the active device is the UI-facing entry you edited first. - If the device looks paired but cron still returns
gateway closed (1008): pairing required, treat runtime-scope mismatch as a prime suspect.
Fix
Update both the paired-device record and the runtime auth record for the actual gateway client so they agree on the full operator set needed for cron management:
operator.readoperator.writeoperator.adminoperator.pairingoperator.approvals
In the reproduced setup, that meant fixing the gateway-client entry in ~/.openclaw/devices/paired.json and the matching runtime scopes in ~/.openclaw/identity/device-auth.json, not just editing a different paired device such as openclaw-control-ui.
After both records matched, cron(action="status") worked again and cron jobs could be created normally.
Operational Lesson
A pairing-related gateway close message does not always mean "this device is unpaired". In practice it can mean "the runtime client is paired but under-scoped for the requested operator action", and the decisive record may live in both paired state and runtime auth state.