Is my gateway actually down when I see this error?

No. The 'gateway closed (1000)' error indicates that the CLI terminated the connection due to a timeout, even if the gateway is running perfectly fine.

Why did this start happening after the update?

OpenClaw 2026.3.12 reduced the allowed handshake time from 10 seconds to 3 seconds. Any system latency that was previously acceptable is now causing the handshake to fail.

Will a future update fix this?

The community is currently tracking this as a regression. It is likely that future patches will either increase the timeout or allow users to configure the threshold via the config file.

How to Fix Handshake Timeout Errors in OpenClaw 2026.3.12

TL;DR — Quick Fix

The handshake timeout was tightened from 10s to 3s in version 2026.3.12; if your gateway is under high load, this causes false-positive connection failures.

Run Diagnostics

Next Step

Fix now, then reduce repeat incidents

If this issue keeps coming back, validate your setup in Doctor first, then harden your config.

Open Doctor Harden Config

Error Signal

gateway connect failed: Error: gateway closed (1000):{"cause":"handshake-timeout","handshake":"failed","durationMs":3770,"handshakeMs":3000}

What's Happening

After updating to version 2026.3.12, your openclaw logs --follow command fails with a 'gateway closed (1000)' error. Even though the gateway itself is healthy and responding to status pings, the CLI kills the connection before the WebSocket handshake can complete.

The Fix

Currently, there is no direct configuration flag to override the timeout duration via the CLI. The most reliable way to mitigate this is to reduce the load on your local gateway before running command-line operations.

If the connection persists in failing, you may need to downgrade to 2026.3.11 until a hotfix increases the timeout threshold back to a more reasonable level for busy systems. You can downgrade via npm:

npm install -g [email protected]

Alternatively, ensure no high-CPU tasks are running on your host machine while executing log commands, as event loop latency is likely delaying the authentication response.

Why This Occurs

The root of this issue is a reduction in the DEFAULT_HANDSHAKE_TIMEOUT_MS constant. It was lowered from 10 seconds to 3 seconds in the latest release to improve security hardening.

When your gateway is under load, the event loop latency prevents the authenticated 'connect' message from being processed within that tight 3-second window. The client sees the connection open, waits for the confirmation, hits the 3s wall, and immediately closes the socket, reporting the gateway as unreachable.

Prevention

Keep your gateway resources monitored. If you notice consistent handshake timeouts, check your host's resource utilization. While waiting for a patch, avoid running intensive background tasks concurrently with OpenClaw CLI operations to give the gateway the headroom it needs to handle the WebSocket handshake quickly.

Last Updated: March 2026

Did this guide solve your problem?