solution gateway medium macos

Gateway restart is slow (`remote bin probe timed out` from a stale paired node)

Fix gateway restart/shutdown delays caused by unreachable or co-located paired nodes triggering repeated remote bin probes. Start with a minimal `gateway.nodes.denyCommands` workaround, then verify restart time returns to normal.

By CoClaw Team • March 18, 2026

Symptoms

openclaw gateway restart or a shutdown/restart signal takes much longer than normal, often 10-30 seconds instead of a fast restart.
Logs repeat this warning during restart:
- remote bin probe timed out (...); check node connectivity
You may also see:
- shutdown timed out; exiting without full cleanup
The slowdown often starts after you paired another node or app, then that node became unreachable, stale, or effectively looped back on the same machine.

If you do not see remote bin probe timed out, this page is probably the wrong fix path.

Cause

Based on issue #28143 and its follow-up comments, this slowdown usually happens when the gateway tries to probe commands on a paired node during restart or shutdown, but that node is no longer responding fast enough.

The practical pattern is:

A paired node exists.
That node is unreachable, stale, version-mismatched, or co-located in a way that still triggers remote probing.
Restart/shutdown waits on repeated probe timeouts in the critical path.

The known workaround is not a full root-cause fix. It is an operational mitigation that removes the expensive probe path for the node commands most strongly associated with this slowdown.

Fix

1) Add the minimal known `denyCommands` workaround

Use the config helper so you do not have to hand-edit JSON:

openclaw config set gateway.nodes.denyCommands '["system.run","system.run.prepare","system.which"]' --strict-json

Why this helps: issue comments on #28143 identify these node commands as the ones that trigger the expensive remote bin probe path during restart/shutdown. Denying them is the fastest known mitigation when the problem matches this symptom family.

2) Restart the gateway and time the next restart

time openclaw gateway restart
openclaw gateway status

If the workaround matched the real cause, restart time should drop back toward the normal fast path instead of hanging across repeated probe timeouts.

3) Keep the deny list minimal

This workaround is intentionally narrow. Do not start by blocking broader node features than necessary.

If you later discover that a real remote-node workflow needs one of these commands, remove only the specific entry you need to re-enable after the upstream probe-path bug is fixed or your topology changes.

Verify

time openclaw gateway restart is materially faster than before.
openclaw gateway status reports the gateway healthy after restart.
Restart logs no longer spam:
- remote bin probe timed out
- shutdown timed out; exiting without full cleanup
openclaw config get gateway.nodes.denyCommands shows:

["system.run","system.run.prepare","system.which"]

When This Is The Wrong Page

Switch to a different fix path if:

restart is slow but there is no remote bin probe timed out evidence
the gateway fails to come back because the service is unloaded or broken after upgrade
your problem is browser/device pairing rather than gateway restart latency