#Subagent spawn fails with 1008 pairing required on loopback gateway (OpenClaw 2026.4.12)

6 messages · Page 1 of 1 (latest)

urban crescent
#

Hey, trying to set up Opus 4.6 as a subagent fallback model but hitting a wall.

What's happening:
Any sessions_spawn call immediately fails with:

gateway closed (1008): pairing required
Gateway target: ws://127.0.0.1:18789
Bind: loopback

Gateway log snippet (repeats every ~1s):

warn gateway security audit: device access upgrade requested reason=scope-upgrade
scopesFrom=operator.read scopesTo=operator.approvals client=gateway-client
error gateway connect failed: GatewayClientRequestError: pairing required

Setup:

• OpenClaw 2026.4.12, macOS, node 25.8.1
• Gateway on loopback with token auth
• Telegram connected and working
• Main agent: MiniMax M2.7
• Subagent model: kie-claude/claude-opus-4-6
• Changelog fix #59555 supposedly covers this but still failing

Main agent works fine (chat, voice notes, heartbeats). Just the subagent spawn is broken.

Any known workaround or is this a remaining edge case?

open scrollBOT
#

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

near heraldBOT
mellow auroraBOT
#

This looks like a pairing/scope issue, not an Opus fallback issue.

2026.4.12 does include the #59555 subagent fix, so on a clean pairing state this should not happen. Your log is the tell:

  • scopesFrom=operator.read
  • scopesTo=operator.approvals
  • reason=scope-upgrade

So the local gateway-client is trying to upgrade its approved operator scopes, and the gateway is rejecting that upgrade with 1008 pairing required.

What I’d try first, on the same Mac as the gateway:

openclaw devices list
openclaw devices approve <requestId>
#

Important:

  • use the exact current requestId
  • if it keeps changing, re-run openclaw devices list right before approving
  • do not pass an explicit --url for this recovery path on local loopback

If that pending request keeps respawning, I’d suspect a stale paired-device record. Then do:

openclaw devices list
openclaw devices remove <deviceId>
# retry one sessions_spawn
openclaw devices list
openclaw devices approve <newRequestId>

So yes, I’d call this a remaining stale pairing / scope-upgrade edge case. The good news is it’s usually recoverable by re-approving or re-pairing the local gateway client.