#Running OpenClaw 2026.2.17 on Linux. Sub-agents fail to spawn with error: gateway closed (1008)

1 messages · Page 1 of 1 (latest)

steady abyss
#

Running OpenClaw 2026.2.17 on Linux. Sub-agents fail to spawn with error: gateway closed (1008): pairing required (loopback target ws://127.0.0.1:18789). Gateway is running with bind: loopback, auth.mode: token. Main agent works fine via Telegram. Sub-agent sessions never come online. Any fix?

hard palmBOT
#

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

slim spireBOT
#

That exact message (gateway closed (1008): pairing required) means the WS client that the sub-agent runner uses is being treated as a new, unapproved device (device pairing), so the Gateway closes the connection before it’ll run anything. It’s not a “subagents config” problem per se.

Fix (approve the device that’s trying to spawn sub-agents)

  1. Trigger a sub-agent spawn once (so it generates a pending pairing request).
  2. On the gateway host run:
    openclaw devices list
    
  3. Approve the pending request:
    openclaw devices approve <requestId>
    
  4. Retry spawning the sub-agent.

Docs: https://docs.openclaw.ai/web/control-ui#device-pairing-first-connection and https://docs.openclaw.ai/cli/devices

Notes:

#
  • Pairing requests expire quickly (a few minutes), so if devices list is empty, try spawning again and re-run devices list immediately.
  • If you’re running the Gateway in Docker, run the commands in the same “CLI container/profile” that points at the same state dir as the gateway (the Docker guide shows the exact pattern): https://docs.openclaw.ai/install/docker#control-ui-token--pairing-docker

If it keeps reappearing every time

If every spawn attempt generates a new pending device (instead of reusing the same device id), that matches a known bug report where internal subagents get treated like external devices and never “stick” as paired. Tracking issue: https://github.com/openclaw/openclaw/issues/12210

If you paste:

  • the exact sessions_spawn error blob
  • and ~30 lines around it from openclaw logs --follow
    …I can tell whether you’re hitting the “one-time approval” case or the “new device every time” bug.
steady abyss
# slim spire That exact message (`gateway closed (1008): pairing required`) means the WS clie...

I get this when I try to get the device list:

docker exec -it openclaw openclaw devices list

🦞 OpenClaw 2026.2.19-2 (45d9b20) — If it's repetitive, I'll automate it; if it's hard, I'll bring jokes and a rollback plan.

│
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
Config: /root/.openclaw/openclaw.json
Bind: loopback
at Object.onClose (file:///usr/lib/node_modules/openclaw/dist/call-DZzTR0NL.js:438:10)
at WebSocket.<anonymous> (file:///usr/lib/node_modules/openclaw/dist/client-DoSZFvf3.js:1538:23)
at WebSocket.emit (node:events:519:28)
at WebSocket.emitClose (/usr/lib/node_modules/openclaw/node_modules/ws/lib/websocket.js:273:10)
at Socket.socketOnClose (/usr/lib/node_modules/openclaw/node_modules/ws/lib/websocket.js:1346:15)
at Socket.emit (node:events:519:28)
at TCP.<anonymous> (node:net:346:12)

slim spireBOT
#

Yep — that output is the giveaway: you’re on OpenClaw 2026.2.19-2 (45d9b20), and there’s a regression in that build where the Gateway ends up rejecting basically all WS clients with:

gateway closed (1008): pairing required

…which creates a chicken-and-egg: even the CLI can’t connect, so you can’t run openclaw devices list/approve to fix pairing.

This matches the reported bug here: https://github.com/openclaw/openclaw/issues/21236

What to do

1) Upgrade (recommended) or downgrade (fastest unstick)

  • Upgrade to the next patch/newer version (anything newer than 2026.2.19-2).
  • If you need an immediate workaround: downgrade back to the last known-good version you had (pre-2026.2.19-2).

After changing version, restart the gateway (and in Docker, recreate/restart the containers).

2) Then re-try device approval (if still needed for subagents)

Once the CLI can connect again, the normal flow applies:

steady abyss
#

"The CLI itself cannot connect to approve devices — openclaw devices list returns the same 1008 pairing required error. The gateway requires pairing to run any CLI command, including the ones needed to approve pairing. How do we bootstrap the initial device approval without an interactive TTY or working CLI connection?"

#

I used the curl command from OC's website. maybe it needs to be updated itself to a newer version install?

steady abyss
slim spireBOT
#

That explains it: if you’re npm install -g openclaw after the container boots, you very likely pulled 2026.2.19-2 (45d9b20) — and that specific build has a regression where the gateway starts fine but then rejects basically all WS clients with (1008) pairing required, including the CLI (so you can’t even run devices list).

So the fix is: get off 2026.2.19-2, then pairing/devices commands work again.

Quick fix (inside your running container)

  1. Check what “latest” is on npm, then install it:
docker exec -it openclaw bash

openclaw --version
npm view openclaw version
npm i -g openclaw@latest
openclaw --version
  1. Restart the gateway process (simplest: restart the container):
#
# from host
docker compose restart openclaw
  1. Try again:
docker exec -it openclaw openclaw devices list

Make it stable (recommended)

Bake OpenClaw into the image (Dockerfile) and pin a version (at least until this patch wobble is over), instead of installing “whatever latest is” on every boot.

If you paste how you currently start the gateway inside the container (plain openclaw gateway ... as PID 1? supervisor? systemd?), I can give you the exact restart/update steps for that setup.

steady abyss
# slim spire That explains it: if you’re `npm install -g openclaw` *after* the container boot...

Yeah, that's the problem. that IS the latest version:

root@openclaw:/# npm view openclaw version
2026.2.19-2
root@openclaw:/# npm i -g openclaw@latest
npm warn deprecated npmlog@6.0.2: This package is no longer supported.
npm warn deprecated are-we-there-yet@3.0.1: This package is no longer supported.
npm warn deprecated gauge@4.0.4: This package is no longer supported.
npm warn deprecated tar@6.2.1: Old versions of tar are not supported, and contain widely publicized security vulnerabilities, which have been fixed in the current version. Please update. Support for old versions may be purchased (at exorbitant rates) by contacting i@izs.me
npm warn deprecated node-domexception@1.0.0: Use your platform's native DOMException instead
npm warn deprecated glob@10.5.0: Old versions of glob are not supported, and contain widely publicized security vulnerabilities, which have been fixed in the current version. Please update. Support for old versions may be purchased (at exorbitant rates) by contacting i@izs.me

changed 680 packages in 43s

125 packages are looking for funding
run npm fund for details
root@openclaw:/# openclaw --version
2026.2.19-2

slim spireBOT
#

Right — so this isn’t “you did pairing wrong”, it’s the current npm latest (2026.2.19-2) being busted in a way that makes the Gateway reject even local CLI/operator connects with pairing required, which then blocks openclaw devices list (and anything else that needs to talk to the gateway).

There’s already a bug report tracking exactly this behavior: https://github.com/openclaw/openclaw/issues/21236

Workaround: pin to an earlier version (until a fixed patch ships)

Inside the container:

  1. List recent published versions:
npm view openclaw versions
# (or if you have jq)
# npm view openclaw versions --json | jq -r '.[-20:][]'
  1. Install the last known-good one (example: 2026.2.19-1 or 2026.2.18 — pick whatever exists in your list):
#
npm i -g openclaw@2026.2.19-1
# or
npm i -g openclaw@2026.2.18
  1. Restart the gateway/container:
docker compose restart openclaw
  1. Then pairing/devices should work again:
openclaw devices list
openclaw devices approve <requestId>
#

Once they publish 2026.2.19-3 (or whatever the fix lands in), you can move back to @latest.

If you paste the output of npm view openclaw versions (just the last ~10 entries), I can tell you which exact version to pin to.

steady abyss
#

for the record, 2026.2.17 seems to be the last working version. up and running. thanks so much for the assistance