node unavailable

[austere iris]

openclaw logs
10:29:49+00:00 info gateway/skills-remote {"subsystem":"gateway/skills-remote"} remote bin probe skipped: node unavailable (f4b1c4e1c2eca3339b0455d3a294b98442796c77c419e6d46e5b51f51e363549; command=system.which timeoutMs=15000 requiredBins=44 connected=no)

[stone lily]

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

[bleak escarp]

That line means the gateway tried to probe a paired/known node for remote skill binaries, but that node was not connected at that moment. It’s usually not fatal by itself; it only matters if you expect a Mac/headless node to be available for system.which / node-host exec.

First, what does openclaw --version show?

Then check the node state:

openclaw nodes status
openclaw devices list

If the node is supposed to be connected, restart/reopen it:

openclaw node status
openclaw node restart

or run it foreground to see the real connection/pairing error:

[bleak escarp]

openclaw node run --host <gateway-host> --port 18789

If devices list shows a pending node request, approve the current requestId:

openclaw devices approve <requestId>

Docs for this path: https://docs.openclaw.ai/nodes and https://docs.openclaw.ai/nodes/troubleshooting

[austere iris]

what is the difference between nodes and devices?

[bleak escarp]

Short version:

Device = the trusted identity/pairing record. It answers: “is this thing allowed to connect to my gateway, and with what role?” You manage that with:

openclaw devices list
openclaw devices approve <requestId>

Node = the live connected capability host. It answers: “what can this connected thing do right now?” For example camera/canvas/screen on mobile/macOS, or system.run / system.which from a headless node host. You inspect that with:

openclaw nodes status
openclaw nodes describe --node <idOrNameOrIp>

So pairing a device is the trust gate; seeing a node connected is the runtime/capability state. A node can have an approved device record but still be unavailable if the app/service is closed, offline, pointed at the wrong gateway, or missing auth.

Docs: https://docs.openclaw.ai/nodes and https://docs.openclaw.ai/gateway/pairing

[austere iris]

openclaw nodes status
🦞 OpenClaw 2026.5.12 (f066dd2) — Claws out, commit in—let's ship something mildly responsible.

│
◇
nodes status failed: GatewayTransportError: gateway timeout after 10000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/yuto/.openclaw/openclaw.json
Bind: loopback

[bleak escarp]

That’s one layer earlier than the node problem: the CLI can’t get a response from the local gateway WebSocket at 127.0.0.1:18789 within 10s. So nodes status is timing out before it can even ask about nodes.

Run these next and paste the output/log tail:

openclaw gateway status
openclaw status --all
openclaw logs --follow

A quick recovery attempt is:

openclaw gateway restart
openclaw health --verbose
openclaw nodes status

If gateway status says the service is running but health / nodes status still time out, the gateway may be wedged rather than stopped. In that case, restart the service and check the latest logs for the first error before the timeout.

[bleak escarp]

Docs: https://docs.openclaw.ai/start/faq#first-60-seconds-if-something-is-broken and https://docs.openclaw.ai/gateway/troubleshooting

[bleak escarp]

This report says the gateway is healthy now:

• Gateway service is running
• WebSocket probe is OK
• CLI and gateway versions match (2026.5.12)
• But: Node service: systemd user not installed

So if you expected a headless node host on this machine, it simply is not installed/running. That would explain the earlier node unavailable probe.

Try:

openclaw nodes status
openclaw nodes list --connected

If no node is connected and you want this machine to be a node host, run either foreground:

[bleak escarp]

openclaw node run --host 127.0.0.1 --port 18789 --display-name "polaris"

or install it as a service:

openclaw node install --host 127.0.0.1 --port 18789 --display-name "polaris"
openclaw node restart

Then approve the pending node request:

openclaw devices list
openclaw devices approve <requestId>
openclaw nodes status

[bleak escarp]

One separate thing I noticed: agent investment still has a bootstrap file present. If that agent is stuck bootstrapping, move/delete its BOOTSTRAP.md and restart the gateway. But that’s separate from the node-host issue.

[austere iris]

11:02:53+00:00 warn gateway/ws {"subsystem":"gateway/ws"} handshake timeout conn=4c180864-4bcb-4142-95ec-ec41654253ac peer=127.0.0.1:42664->127.0.0.1:18789 remote=127.0.0.1
11:02:53+00:00 warn diagnostic {"subsystem":"diagnostic"} liveness warning: reasons=event_loop_delay interval=40s eventLoopDelayP99Ms=436.5 eventLoopDelayMaxMs=19310.6 eventLoopUtilization=0.644 cpuCoreRatio=0.653 active=1 waiting=0 queued=1 phase=channels.discord.start-account recentPhases=sidecars.main-session-recovery:4ms,sidecars.restart-sentinel:29ms,post-attach.update-sentinel:16ms,sidecars.session-locks:354ms,sidecars.model-prewarm:976ms,post-ready.maintenance:3ms work=[active=agent:main:discord:direct:1490627767384150106(processing,q=1,age=20s last=embedded_run:ended) queued=agent:main:discord:direct:1490627767384150106(processing,q=1,age=20s last=embedded_run:ended)]
11:02:53+00:00 warn gateway/ws {"subsystem":"gateway/ws"} {"cause":"handshake-timeout","handshake":"failed","durationMs":19337,"lastFrameType":"req","lastFrameMethod":"connect","lastFrameId":"CD55F41F-E3E4-455B-961B-666B73BFC821","host":"polaris.tail8a307f.ts.net","userAgent":"OpenClaw/2026051290 CFNetwork/3860.600.21 Darwin/25.5.0","forwardedFor":"100.107.21.34","remoteAddr":"127.0.0.1","remotePort":42664,"localAddr":"127.0.0.1","localPort":18789,"endpoint":"127.0.0.1:42664->127.0.0.1:18789","handshakeMs":19330} closed before connect conn=4c180864-4bcb-4142-95ec-ec41654253ac peer=127.0.0.1:42664->127.0.0.1:18789 remote=127.0.0.1 fwd=100.107.21.34 origin=n/a host=polaris.tail8a307f.ts.net ua=OpenClaw/2026051290 CFNetwork/3860.600.21 Darwin/25.5.0 code=1000 reason=n/a

[bleak escarp]

This log is the important bit:

liveness warning: reasons=event_loop_delay ... eventLoopDelayMaxMs=19310.6 ...
handshake-timeout ... userAgent=OpenClaw/... Darwin ... forwardedFor=100.107.21.34

So the Darwin node/app did reach the gateway through Tailscale, but the gateway event loop was blocked for up to ~19s, and the node handshake timed out before connect completed. That makes the later node unavailable message a symptom, not the root cause.

Do this in order:

openclaw gateway restart
openclaw health --verbose
openclaw nodes status

If it comes back, reconnect/reopen the Mac/iOS node app and approve any new request: