#Running OpenClaw 2026.2.17 on Linux. Sub-agents fail to spawn with error: gateway closed (1008)
1 messages · Page 1 of 1 (latest)
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)
- Trigger a sub-agent spawn once (so it generates a pending pairing request).
- On the gateway host run:
openclaw devices list - Approve the pending request:
openclaw devices approve <requestId> - 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 listis empty, try spawning again and re-rundevices listimmediately. - 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_spawnerror 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.
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)
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:
openclaw devices list
openclaw devices approve <requestId>
Docker docs for this exact flow: https://docs.openclaw.ai/install/docker#control-ui-token--pairing-docker
Devices CLI: https://docs.openclaw.ai/cli/devices
Quick sanity check question
Are you running the official docker-compose setup (openclaw-gateway + openclaw-cli) or a single custom container named openclaw?
(If it’s compose, I’ll give you the exact docker compose ... commands to bump the version + restart cleanly.)
"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?
it's just a base ubuntu 24.04 container (via compose) with the install AFTER container boot.
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)
- 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
- Restart the gateway process (simplest: restart the container):
# from host
docker compose restart openclaw
- 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.
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
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:
- List recent published versions:
npm view openclaw versions
# (or if you have jq)
# npm view openclaw versions --json | jq -r '.[-20:][]'
- 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
- Restart the gateway/container:
docker compose restart openclaw
- 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.
for the record, 2026.2.17 seems to be the last working version. up and running. thanks so much for the assistance