#Subagent spawn failing with "pairing required" on loopback ā€” need help

1 messages Ā· Page 1 of 1 (latest)

burnt sedge
#

Running OpenClaw 2026.4.18 on WSL2 (Windows 11). When my agent tries to spawn a subagent via sessions_spawn, it fails with:

gateway closed (1008): pairing required
Gateway target: ws://127.0.0.1:18790
Source: local loopback

Things I've tried:

ā€¢ openclaw gateway restart (multiple times)
ā€¢ openclaw gateway install --force
ā€¢ openclaw doctor --fix
ā€¢ Deleted ~/.openclaw/identity/device-auth.json and let it regenerate
ā€¢ Passed --token explicitly to CLI commands
ā€¢ Updated to 2026.4.18

The device-auth.json always re-pairs with only operator.approvals scope ā€” never gets operator.write or broader scopes. I think this is why subagent spawns are rejected.

Auth config in openclaw.json:

"gateway": {
"auth": {
"mode": "token",
"token": "..."
},
"bind": "loopback"
}

The main Telegram session works fine ā€” I can chat with the agent normally. It's only subagent spawning and cron isolated sessions that fail. Cron main-session jobs also fail with the same error when added via CLI or the cron tool inside the agent.

Any idea what's causing the limited device scope and how to get full operator access for local CLI/subagent use?

vernal escarpBOT
worn raptorBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> āœ… Mark Solution

vernal escarpBOT
unreal tuskBOT
#

Short version, this is probably a stale/narrow device pairing contract, not just the shared gateway token.

A few important bits:

  • operator.pairing is not auto-granted by bootstrap. By design, bootstrap operator handoff is limited to operator.approvals, operator.read, operator.talk.secrets, and operator.write.
  • For sessions_spawn, the important one is usually operator.write. If your device only has operator.approvals, subagent spawns will fail.
  • Deleting ~/.openclaw/identity/device-auth.json only clears the local cached token. It does not reset the gateway-side paired device record / approved scope baseline.

What Iā€™d do next:

  1. Check the gateway-side device state:
    openclaw devices list --json
    Look for:
    • a pending request from the same device with broader scopes like operator.write
    • the existing paired device entry and its approved scopes
#

  1. If there is a newer pending request that asks for broader scopes, approve that exact request:

    openclaw devices approve <requestId>

  2. If there is no upgrade request, and the paired device is stuck at operator.approvals only, then the paired device entry itself is likely stale. In that case, remove that paired device entry, trigger one failing sessions_spawn again so it creates a fresh pending request, then approve the new request.

Also, one nuance: if you want to manage devices / rotate device tokens from device-token auth, that needs operator.pairing (or operator.admin). Bootstrap will not hand that out automatically.

Docs:

If you paste these two outputs, I can tell you exactly which device/request is the bad one: