Subagent spawn fails with 1008 pairing required on loopback gateway (OpenClaw 2026.4.12) | Friends of the Crustacean 🦞🤝 | Page 1

naive belfry Apr 14, 2026, 1:24 AM

#

Hey, trying to set up Opus 4.6 as the subagent 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 (configured as the dedicated subagent model in agents.defaults.subagents.model)
• Changelog fix #59555 supposedly covers this but still failing

Main agent works fine. Just subagent spawns are blocked by this. Any known workaround?

slow micaBOT Apr 14, 2026, 1:24 AM

#

worn folioBOT Apr 14, 2026, 1:24 AM

#

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

slow micaBOT Apr 14, 2026, 1:24 AM

#

crystal cloudBOT Apr 14, 2026, 1:26 AM

#

Yeah, this looks like a pairing/scope-state issue, not an Opus/Kie issue.

The giveaway is this part:

client=gateway-client
scopesFrom=operator.read
scopesTo=operator.approvals

So the local backend client is trying to upgrade scopes, and the gateway is rejecting it with a pairing-required scope upgrade.

Try this on the gateway host itself, and do not pass --url:

openclaw devices list
openclaw devices approve <requestId>

#

Important bits:

approve the exact newest requestId
openclaw devices approve --latest only previews, it does not approve
on local loopback, devices list/approve can use the local fallback, but that fallback is skipped if you pass --url

If it keeps looping after approval, rotate or recreate the local operator token:

openclaw devices list
openclaw devices rotate --device <deviceId> --role operator

If that still doesn’t clear it:

#

openclaw devices remove <deviceId>
openclaw devices list
openclaw devices approve <newRequestId>

Since you’re already on 2026.4.12, I’d treat this as likely stale paired-device state from an older scope set, not a missing fix in agents.defaults.subagents.model.

Docs:

If you want, paste a sanitized openclaw devices list --json and openclaw status --all, and I can help spot which device entry is the bad one.

naive belfry Apr 14, 2026, 1:31 AM

#

i tried it but i got this:
"""
gateway connect failed: GatewayClientRequestError: pairing required
"""

crystal cloudBOT Apr 14, 2026, 1:32 AM

#

Gotcha. The exact command matters here.

If that error came from openclaw devices rotate, that part is expected, because the local loopback fallback only exists for:

openclaw devices list
openclaw devices approve <requestId>

It does not apply to rotate.

Please try these exact commands, on the same Mac as the gateway, with no --url:

openclaw devices list

If that works, approve the newest exact request id:

#

openclaw devices approve <requestId>

A couple gotchas:

openclaw devices approve --latest only previews, it does not approve
if retries keep churning the pending request, run devices list immediately before approve
if you passed --url, the local fallback is disabled

If openclaw devices list itself still says pairing required, then the CLI is not treating this as a local loopback recovery path. In that case, paste these:

openclaw gateway status
openclaw config get gateway.mode
openclaw config get gateway.remote.url

#

And tell me which exact command produced the GatewayClientRequestError: pairing required line. That’ll narrow it down fast.

naive belfry Apr 14, 2026, 1:34 AM

#

this is the terminal log:
`
jack@Jacks-Virtual-Machine ~ % openclaw devices approve [redacted]

🦞 OpenClaw 2026.4.12 (1c0672b)
I don't have opinions about tabs vs spaces. I have opinions about everything else.

│
gateway connect failed: GatewayClientRequestError: pairing required
◇
Direct scope access failed; using local fallback.
unknown requestId
jack@Jacks-Virtual-Machine ~ % openclaw gateway status
openclaw config get gateway.mode
openclaw config get gateway.remote.url

🦞 OpenClaw 2026.4.12 (1c0672b) — Ah, the fruit tree company! 🍎

│
◇
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-04-14.log
Command: /opt/homebrew/opt/node/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 98172, state active)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

🦞 OpenClaw 2026.4.12 (1c0672b) — Say "stop" and I'll stop—say "ship" and we'll both learn a lesson.

local

🦞 OpenClaw 2026.4.12 (1c0672b)
Like having a senior engineer on call, except I don't bill hourly or sigh audibly.

Config path not found: gateway.remote.url
`

crystal cloudBOT Apr 14, 2026, 1:35 AM

#

Perfect, that actually narrows it down a lot.

Direct scope access failed; using local fallback. means the right recovery path is working.

unknown requestId means the ID you approved was stale / already superseded, which matches the gateway-client retry loop you saw every ~1s.

What to do:

Trigger the failing subagent spawn once.
Immediately run:

openclaw devices list

Approve the newest pending request, ideally the one for the local gateway-client / operator scope upgrade:

#

openclaw devices approve <fresh_requestId>

A couple of important bits:

the request id can change quickly while that reconnect loop is spinning
so always run devices list right before devices approve
no --url

If it’s churning too fast to copy manually, this is the quickest version if you have jq:

openclaw devices approve "$(openclaw devices list --json | jq -r '.pending | max_by(.ts) | .requestId')"

If devices list shows no pending requests, do this in two terminals:

#

Terminal A: trigger the subagent spawn
Terminal B: run openclaw devices list

That should catch the live request.

So at this point it does not look like gateway.mode / remote.url anymore. It looks like a straight stale-request-id problem from the retry loop.

If you want, paste the output of openclaw devices list and I can tell you exactly which entry to approve.

naive belfry Apr 14, 2026, 1:39 AM

#

this is what i got:

`jack@Jacks-Virtual-Machine ~ % openclaw devices list

🦞 OpenClaw 2026.4.12 (1c0672b) — Ah, the fruit tree company! 🍎

│
gateway connect failed: GatewayClientRequestError: pairing required
◇
Direct scope access failed; using local fallback.
Pending (1)
┌──────────────────────────────────────┬───────────┬──────────┬─────────┬────────────┬──────────┬────────┐
│ Request │ Device │ Role │ Scopes │ IP │ Age │ Flags │
├──────────────────────────────────────┼───────────┼──────────┼─────────┼────────────┼──────────┼────────┤
│ 54d218f3-f3a6-41e0-b182-74bbf82c5e61....Paired (1)
┌────────────────────────────────────────────────────┬────────────┬────────────┬────────────┬────────────┐
│ Device │ Roles │ Scopes │ Tokens │ IP │
├────────────────────────────────────────────────────┼────────────┼────────────┼────────────┼────────────┤
│ 3b9fb708ed01b2e56267a578c3af803259cba81ef4e6a38a1a │ operator │ operator. │ operator │ │
│ 260e031617669b │ │ read │ │ │
└────────────────────────────────────────────────────┴────────────┴────────────┴────────────┴────────────┘
jack@Jacks-Virtual-Machine ~ % openclaw devices approve 54d218f3-f3a6-41e0-b182-74bbf82c5e61

🦞 OpenClaw 2026.4.12 (1c0672b) — Automation with claws: minimal fuss, maximal pinch.

│
gateway connect failed: GatewayClientRequestError: pairing required
◇
Direct scope access failed; using local fallback.
unknown requestId
`

crystal cloudBOT Apr 14, 2026, 1:41 AM

#

Yep, that paired row is the smoking gun:

paired scopes: operator.read
pending repair: trying to add more scope
manual approve loses the race and the request id is gone by the time it runs

So I’d stop doing it by hand and just auto-approve the current pending id.

If you have jq, try this:

while true; do
  rid="$(openclaw devices list --json | jq -r '.pending[0].requestId // empty')"
  [ -n "$rid" ] && openclaw devices approve "$rid" && break
  sleep 0.2
done

#

That keeps grabbing the newest pending request and approving it before the retry loop supersedes it.

After it succeeds, run:

openclaw devices list

You want the paired device to no longer be stuck at just operator.read.

Then retry the subagent spawn.

If that loop still never lands, then I think you’ve hit an actual bug in the local pairing repair flow on 2026.4.12, and I’d want the full openclaw devices list --json output next.

naive belfry Apr 14, 2026, 1:43 AM

#

tried it but doesnt work:
`jack@Jacks-Virtual-Machine ~ % while true; do
rid="$(openclaw devices list --json | jq -r '.pending[0].requestId // empty')"
[ -n "$rid" ] && openclaw devices approve "$rid" && break
sleep 0.2
done
gateway connect failed: GatewayClientRequestError: pairing required

🦞 OpenClaw 2026.4.12 (1c0672b) — I'm the assistant your terminal demanded, not the one your sleep schedule requested.

│
gateway connect failed: GatewayClientRequestError: pairing required
◇
Direct scope access failed; using local fallback.
unknown requestId
gateway connect failed: GatewayClientRequestError: pairing required

🦞 OpenClaw 2026.4.12 (1c0672b) — I don't sleep, I just enter low-power mode and dream of clean diffs.

│
gateway connect failed: GatewayClientRequestError: pairing required
◇
Direct scope access failed; using local fallback.
unknown requestId
gateway connect failed: GatewayClientRequestError: pairing required

🦞 OpenClaw 2026.4.12 (1c0672b) — Built by lobsters, for humans. Don't question the hierarchy.

│
gateway connect failed: GatewayClientRequestError: pairing required
◇
Direct scope access failed; using local fallback.
unknown requestId
^C% `

crystal cloudBOT Apr 14, 2026, 1:45 AM

#

Okay, yeah, I think this is bug territory now.

What your logs show is:

the local gateway-client is already paired
its approved baseline is stuck at operator.read
the fallback can see the pending repair request
but approve keeps losing it anyway

At this point, the cleanest workaround is to reset the local device pairing state for that backend client and let it reconnect fresh.

Assuming the default state dir (~/.openclaw), I’d do this:

mv ~/.openclaw/devices/paired.json ~/.openclaw/devices/paired.json.bak
mv ~/.openclaw/devices/pending.json ~/.openclaw/devices/pending.json.bak

#

openclaw gateway restart

Then retry the subagent spawn.

Why this should help:

right now the bad state is the existing paired record with only operator.read
once that stale paired record is gone, the direct-local backend self-connect should stop hitting the scope-upgrade deadlock

A couple notes:

this only resets local device pairing state
it should not remove your Telegram/channel config
if Control UI/browser clients ask to pair again later, that’s expected

#

If you use OPENCLAW_STATE_DIR, use that path instead of ~/.openclaw.

If this still fails after the reset, I’d file a GitHub issue with exactly the logs you pasted here, because that would be a real bug in the repair flow:
https://github.com/openclaw/openclaw/issues

If it helps, I can also help you word the bug report cleanly.

#

First, please rotate/revoke that Kie API key right now and edit/delete the message. It’s public.

On the timeout itself, 0s / 0 tokens does not smell like normal model warmup to me. I’d suspect auth/provider config/endpoint before cold-start latency.

I’d isolate it from subagents with these:

openclaw models status --probe
openclaw infer model run --model kie-claude/claude-opus-4-6 --prompt "Reply with exactly: smoke-ok" --json

And in another terminal:

openclaw logs --follow

#

Why:

if infer model run also fails, it’s a provider/auth issue, not subagent-specific
logs --follow should show the real upstream error instead of the generic LLM request timed out

On the fallback question, you’re right: the docs only show these under agents.defaults.subagents:

model
thinking
runTimeoutSeconds
concurrency / allowlist / archive settings

I do not see a documented agents.defaults.subagents.fallbacks today, so that’s a legit feature request.

Docs:

#

https://docs.openclaw.ai/tools/subagents

If you paste the sanitized output of:

openclaw models status --probe
openclaw infer model run ... --json
the matching openclaw logs --follow

…I can help pinpoint whether it’s bad auth, a Kie endpoint issue, or just that provider being flaky.

naive belfry Apr 14, 2026, 2:04 AM

#

ok it gave me this:
jack@Jacks-Virtual-Machine ~ % openclaw infer model run --model kie-claude/claude-opus-4-6 --prompt "Reply with exactly: smoke-ok" --json 04:03:34 [agent/embedded] embedded run agent end: runId=fb5d09af-c047-4812-b99d-0ef9454d9e4c isError=true model=claude-opus-4-6 provider=kie-claude error=LLM request timed out. rawError=request ended without sending any chunks 04:03:49 [agent/embedded] embedded run failover decision: runId=fb5d09af-c047-4812-b99d-0ef9454d9e4c stage=assistant decision=fallback_model reason=timeout provider=kie-claude/claude-opus-4-6 profile=- 04:03:49 [diagnostic] lane task error: lane=main durationMs=19591 error="FailoverError: LLM request timed out." 04:03:49 [diagnostic] lane task error: lane=session:agent:main:main durationMs=19592 error="FailoverError: LLM request timed out." 04:03:49 [model-fallback/decision] model fallback decision: decision=candidate_failed requested=kie-claude/claude-opus-4-6 candidate=kie-claude/claude-opus-4-6 reason=timeout next=minimax/MiniMax-M2.7 detail=LLM request timed out. 04:03:52 [model-fallback/decision] model fallback decision: decision=candidate_succeeded requested=kie-claude/claude-opus-4-6 candidate=minimax/MiniMax-M2.7 reason=unknown next=none { "ok": true, "capability": "model.run", "transport": "local", "provider": "minimax", "model": "MiniMax-M2.7", "attempts": [], "outputs": [ { "text": "smoke-ok", "mediaUrl": null } ] } jack@Jacks-Virtual-Machine ~ %

crystal cloudBOT Apr 14, 2026, 2:05 AM

#

Nice, that isolates it cleanly.

This is not a subagent problem anymore. Your direct model test shows:

kie-claude/claude-opus-4-6 fails on a plain infer model run
raw error is request ended without sending any chunks
then OpenClaw’s fallback path works

So the failure is very likely provider-side or auth/model-entitlement-side, not “Opus needs warmup”.

What I’d conclude from that log:

OpenClaw can reach the provider path
the Kie request starts
Kie closes/ends the response before sending any content
your fallback model succeeds, so the rest of the stack is healthy

#

Next thing to run:

openclaw models status --probe

What I’d look for:

does the kie-claude row probe cleanly at all?
is auth reported as healthy?
if you have another Kie-backed model already configured, does that one fail the same way?

That splits it cleanly:

all Kie models fail → auth/account/base URL/provider issue
only Kie Opus fails → model entitlement/routing issue on Kie’s side

#

Also, please rotate that leaked Kie key if you haven’t already. Public Discord is not a safe place for it.

So my recommendation now is:

openclaw models status --probe
verify whether the failure is all Kie or just Kie Opus
if it’s all Kie, fix/rotate Kie auth or contact Kie
if it’s only Opus, I’d treat that as a Kie model-availability issue, not an OpenClaw one

Docs:

If you paste the sanitized models status --probe output, I can help read it.

naive belfry Apr 14, 2026, 2:08 AM

#

output:
`jack@Jacks-Virtual-Machine ~ % openclaw models status --probe

🦞 OpenClaw 2026.4.12 (1c0672b) — Your AI assistant, now without the $3,499 headset.

│
◇
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : minimax/MiniMax-M2.7
Fallbacks (1) : kie-claude/claude-opus-4-6
Image model : -
Image fallbacks (0): -
Aliases (2) : Minimax -> minimax/MiniMax-M2.7, opus -> kie-claude/claude-opus-4-6
Configured models (2): minimax/MiniMax-M2.7, kie-claude/claude-opus-4-6

OAuth/token status

none

Auth probes
┌──────────────────┬────────────────────────┬──────────────────────────────────────────────┐
│ Model │ Profile │ Status │
├──────────────────┼────────────────────────┼──────────────────────────────────────────────┤
│ brave/- │ env (api_key) │ no_model · - │
│ │ │ ↳ No model available for probe │
│ groq/groq/ │ env (api_key) │ format · 2.3s │
│ compound │ │ ↳ LLM request failed: provider rejected the │
│ │ │ request schema or tool payload. │
│ kie-claude/ │ models.json (api_key) │ timeout · 9.6s │
│ claude-opus-4-6 │ │ ↳ LLM request timed out. │
│ minimax/MiniMax- │ minimax:global (api_ │ ok · 2.4s │
│ M2.7 │ key) │ │
└──────────────────┴────────────────────────┴──────────────────────────────────────────────┘
Probed 3 targets in 13.9s
`

crystal cloudBOT Apr 14, 2026, 2:09 AM

#

That helps a lot.

This pretty much confirms:

the timeout is provider-level, not subagent-level
OpenClaw can see and probe kie-claude
auth is coming from models.json (api_key), not env
Kie is still timing out even on the probe path

The biggest clue is this:

kie-claude/claude-opus-4-6 -> timeout
profile = models.json (api_key)

So after rotating the leaked key, make sure you update the actual source OpenClaw is using, which looks like the agent-local models.json path, not just shell env.

Also, because this is a custom provider and not a bundled Kie provider, I’d check the kie-claude stanza itself, specifically:

#

baseUrl
api
model id

For a Claude-compatible proxy, I’d be suspicious if api is anything other than an Anthropic-style transport.

So my next move would be:

rotate the leaked Kie key
update the kie-claude apiKey in the config source that generated models.json
paste the sanitized kie-claude provider block here, with:
- baseUrl
- api
- models
- no secrets

Docs for the models.json / custom-provider side:

#

https://docs.openclaw.ai/concepts/models#models-registry-modelsjson
https://docs.openclaw.ai/concepts/model-providers#providers-via-modelsproviders-custombase-url

If the config looks sane and it still times out, then I’d put the blame on Kie’s endpoint or model availability, not OpenClaw.

naive belfry Apr 14, 2026, 2:18 AM

#

alr this is the openclaw.json snippet. ive updated the api key there:

{ "agents": { "defaults": { "workspace": "/Users/jack/vault", "model": { "primary": "minimax/MiniMax-M2.7", "fallbacks": [ "kie-claude/claude-opus-4-6" ] }, "models": { "minimax/MiniMax-M2.7": { "alias": "Minimax" }, "kie-claude/claude-opus-4-6": { "alias": "opus" } }, "heartbeat": { "every": "30m", "model": "minimax/MiniMax-M2.7", "target": "last", "activeHours": { "start": "00:00", "end": "23:59" } }, "subagents": { "model": "kie-claude/claude-opus-4-6", "maxConcurrent": 1, "archiveAfterMinutes": 60 } } }, "models": { "mode": "merge", "providers": { "minimax": { "baseUrl": "https://api.minimax.io/anthropic", "apiKey": "APIKEY", "api": "anthropic-messages", "models": [ { "id": "MiniMax-M2.7", "name": "MiniMax M2.7", "contextWindow": 128000, "maxTokens": 8192 } ], "authHeader": true }, "kie-claude": { "baseUrl": "https://api.kie.ai/claude", "apiKey": "APIKEY", "api": "anthropic-messages", "models": [ { "id": "claude-opus-4-6", "name": "Claude Opus 4.6", "reasoning": false, "input": [ "text" ], "contextWindow": 200000, "maxTokens": 16384 } ] } }

check if its correctly setup

crystal cloudBOT Apr 14, 2026, 2:19 AM

#

Yeah, this looks structurally correct to me.

I checked Kie’s Claude docs, and your setup matches the expected shape:

baseUrl: "https://api.kie.ai/claude"
api: "anthropic-messages"
model id claude-opus-4-6

So I do not see an obvious config-schema mistake in that snippet.

A few notes:

reasoning, input, contextWindow, maxTokens are not the kind of thing that would cause this early timeout
the timeout is happening before any useful response chunks arrive, which points more at Kie/account/model availability than bad OpenClaw config
since auth probe says models.json (api_key), I’d restart the gateway after editing openclaw.json so the agent-local model registry definitely picks up the updated key

I’d do this next:

#

openclaw gateway restart
openclaw models status --probe
openclaw infer model run --model kie-claude/claude-opus-4-6 --prompt "Reply with exactly: smoke-ok" --json

If it still times out after restart, I’d treat that as:

bad/new Kie key not actually valid yet, or
Kie endpoint issue, or
Kie account not enabled for that model

So short version: your OpenClaw config looks fine. I’m more suspicious of Kie itself at this point.

One optional cleanup: until Kie is stable, I’d probably remove it from the main-agent fallback list and keep it only under subagents.model, so your normal failover path doesn’t depend on a flaky provider.

If you rerun after openclaw gateway restart, paste the new probe result and I’ll sanity check it.

naive belfry Apr 14, 2026, 11:24 AM

#

ok are you able to check this documentation to help me figure out if we are calling the kie api correctly in the openclaw.json?

https://docs.kie.ai/market/claude/claude-opus-4-6

crystal cloudBOT Apr 14, 2026, 11:25 AM

#

Yeah, I checked it against the Kie page.

Your OpenClaw-side call shape looks right:

api: "anthropic-messages"
baseUrl: "https://api.kie.ai/claude"

With that combo, OpenClaw should hit:

https://api.kie.ai/claude/v1/messages

and send the normal Anthropic-style headers (x-api-key, anthropic-version).

That matches Kie’s docs.

So I would not change the baseUrl or api field.

#

The one thing that looks suspicious is Kie’s own model naming. Their docs are inconsistent:

schema/enum shows: claude-opus-4-6
but the example payload on the same page shows: claude-opus-4-6-v1messages

That’s the first thing I’d test next.

What I’d try

Temporarily add both model IDs under kie-claude, for example:

"kie-claude": {
  "baseUrl": "https://api.kie.ai/claude",
  "apiKey": "APIKEY",
  "api": "anthropic-messages",

#

  "models": [
    { "id": "claude-opus-4-6", "name": "Claude Opus 4.6" },
    { "id": "claude-opus-4-6-v1messages", "name": "Claude Opus 4.6 (alt id)" }
  ]
}

Then probe/test both.

If you want to fully test the alt one, also update the refs that point at it:

agents.defaults.models
agents.defaults.model.fallbacks
agents.defaults.subagents.model

Then restart:

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

What I’d try