openclaw - 💡(How to fix) Fix [Bug]: `openclaw nodes list` intermittently times out on local loopback and can wedge follow-up gateway probe (2026.4.25) [1 comments, 2 participants]

Bug type

Behavior/performance bug

Summary

openclaw nodes list intermittently times out against a healthy-looking local loopback gateway on 2026.4.25, and in some failure windows the timeout also spills over into openclaw gateway probe, suggesting nodes.list can still wedge or starve gateway RPC handling.

Steps to reproduce

Environment:

• OpenClaw 2026.4.25 (aa36ee6)
• Linux 6.17.0-22-generic x64
• Node.js v25.8.2
• Gateway target: ws://127.0.0.1:18789
• Source: local loopback
• Config: local default OpenClaw config
• Paired nodes: 4

Observed by operator first:

• openclaw nodes list failed with the same timeout on about a dozen sequential attempts.

Local repro from the same installation:

1. Run openclaw nodes list repeatedly.
2. Observe intermittent 10s gateway timeouts.
3. In some failure windows, immediately run openclaw gateway probe.

Actual behavior

Two immediate repro attempts timed out, then a third succeeded only after ~11s:

--- attempt 1 ---
exit=1 duration=13.02s
STDERR:
nodes list failed: Error: gateway timeout after 10000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: ~/.openclaw/openclaw.json
Bind: auto

--- attempt 2 ---
exit=1 duration=12.36s
STDERR:
nodes list failed: Error: gateway timeout after 10000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: ~/.openclaw/openclaw.json
Bind: auto

--- attempt 3 ---
exit=0 duration=11.14s
STDOUT:
Pending: 0 · Paired: 4

Paired
┌──────────┬───────────────┬──────────────────┬──────────────┐
│ Node     │ ID            │ IP               │ Last Connect │
├──────────┼───────────────┼──────────────────┼──────────────┤
│ <redacted> │ <redacted> │ <private-lan-ip> │ 1h ago       │
│ <redacted> │ <redacted> │                  │ 1h ago       │
│ <redacted> │ <redacted> │ <private-lan-ip> │ 1h ago       │
│ <redacted> │ <redacted> │ <private-lan-ip> │ 1h ago       │
└──────────┴───────────────┴──────────────────┴──────────────┘

A separate controlled run showed the failure can affect immediate follow-up RPC probes too:

attempt=1 exit=1
nodes list failed: Error: gateway timeout after 10000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: ~/.openclaw/openclaw.json
Bind: auto
--- probe after failed nodes.list ---
Gateway Status
Reachable: no
Capability: unknown
Probe budget: 3000ms

Discovery (this machine)
Found 0 gateways via Bonjour (local.)
Tip: if the gateway is remote, mDNS won’t cross networks; use Wide-Area Bonjour (split DNS) or SSH tunnels.

Targets
Local loopback ws://127.0.0.1:18789
  Connect: failed - timeout · Capability: unknown

Even after a 12s cooldown in that failure window:

Gateway Status
Reachable: no
Capability: unknown
Probe budget: 3000ms

Targets
Local loopback ws://127.0.0.1:18789
  Connect: failed - timeout · Capability: unknown

--- nodes list after cooldown ---
exit 1
nodes list failed: Error: gateway timeout after 10000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: ~/.openclaw/openclaw.json
Bind: auto

Expected behavior

• openclaw nodes list should return promptly and reliably when the gateway is otherwise healthy.
• If a node is slow/offline, the slowdown should be isolated to node enumeration rather than degrading loopback RPC reachability.
• A failed nodes.list should not make an immediate openclaw gateway probe timeout against the same loopback gateway.

Why this may be a regression / related line

This looks related to earlier closed issues around node.list blocking or handshake failures:

• #55625
• #64926
• #45918

Those appear closed, but the behavior above still reproduces on 2026.4.25, so either the underlying problem is not fully fixed or there is a new variant/regression in the same path.

Impact

• Node management becomes unreliable from the CLI.
• In failure windows, gateway RPC appears partially wedged even for simple probe traffic.
• The problem is frequent enough to be user-visible and repeatable in ordinary use.

Additional information

openclaw status during the session still reported the gateway as running; the failure was specifically in loopback RPC responsiveness during/after nodes.list attempts.