openclaw - 💡(How to fix) Fix CLI handshake timeout when plugins take >3s to load [1 participants]

aunknown · 2026-03-28T07:22:47Z

[openclaw] openclaw cron run --expect-final --timeout 120000` fails with: ``` gateway connect failed: Error: gateway closed (1000): Error: gateway closed (1000 normal closure): no close reason ``` ## Summary `openclaw cron run --expect-final --timeout 120000` fails with: ``` gateway connect failed: Error: gateway closed (1000): Error: gateway closed (1000 normal closure): no close reason ``` ## Root Cause The gateway WebSocket handshake timeout is hardcoded at **3 seconds** (`DEFAULT_HANDSHAKE_TIMEOUT_MS = 3e3`). When the CLI process loads multiple plugins before completing the handshake, plugin initialization can take **8+ seconds**, exceeding the timeout. **Timeline from logs:** 1. CLI process starts, begins loading plugins 2. Gateway detects new WebSocket connection, starts 3s handshake timer 3. At ~3s: gateway logs `handshake timeout conn= remote=127.0.0.1` 4. At ~8s: CLI finishes plugin init, but connection already closed 5. CLI receives `gateway closed (1000): no close reason` **Gateway log evidence:** ``` gateway/ws: handshake timeout conn= remote=127.0.0.1 gateway/ws: closed before connect cause=handshake-timeout, handshakeMs=3000, durationMs=8874 ``` ## Current Behavior - `DEFAULT_HANDSHAKE_TIMEOUT_MS` is hardcoded to `3000` - `OPENCLAW_TEST_HANDSHAKE_TIMEOUT_MS` env var exists but is gated behind `process.env.VITEST`, so it only works in test environments - No config file option (e.g., `gateway.handshakeTimeoutMs`) exists - The CLI loads all discovered plugins **before** completing the WebSocket handshake ## Impact - Only affects CLI-initiated commands (`openclaw cron run`, etc.) - Scheduled cron execution via the internal scheduler is **not affected** (runs inside the gateway process) - More plugins installed = higher chance of hitting this timeout - Environments with non-bundled plugins (custom extensions) are particularly affected ## Suggested Fix (any of these would help) 1. **Expose a config option** like `gateway.handshakeTimeoutMs` (or `gateway.ws.handshakeTimeoutMs`) to allow users to increase the timeout 2. **Increase the default** — 3s is tight when multiple plugins need to initialize; 10-15s would be safer 3. **Reorder CLI startup** — complete the WebSocket handshake first, then load plugins (best fix, but likely more invasive) 4. **Ungating the env var** — allow `OPENCLAW_TEST_HANDSHAKE_TIMEOUT_MS` to work outside of VITEST as a quick escape hatch ## Environment - OpenClaw version: 2026.3.13 - Node: v22.22.0 - OS: Linux (x64) - Non-bundled plugins: 6 (including custom extensions) ## Reproduction 1. Install several non-bundled plugins/extensions 2. Run `openclaw cron run --expect-final --timeout 120000` 3. Observe handshake timeout if plugin init exceeds 3s

openclaw2026-03-28 07:22:47

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#56254•Fetched 2026-04-08 01:43:05

View on GitHub

Comments

Participants

Timeline

Reactions

Author

aunknown

Participants

aunknown

openclaw cron run <job-id> --expect-final --timeout 120000 fails with:

gateway connect failed: Error: gateway closed (1000): 
Error: gateway closed (1000 normal closure): no close reason

Error Message

gateway connect failed: Error: gateway closed (1000): Error: gateway closed (1000 normal closure): no close reason

Root Cause

The gateway WebSocket handshake timeout is hardcoded at 3 seconds (DEFAULT_HANDSHAKE_TIMEOUT_MS = 3e3). When the CLI process loads multiple plugins before completing the handshake, plugin initialization can take 8+ seconds, exceeding the timeout.

Timeline from logs:

CLI process starts, begins loading plugins
Gateway detects new WebSocket connection, starts 3s handshake timer
At ~3s: gateway logs handshake timeout conn=<id> remote=127.0.0.1
At ~8s: CLI finishes plugin init, but connection already closed
CLI receives gateway closed (1000): no close reason

Gateway log evidence:

gateway/ws: handshake timeout conn=<id> remote=127.0.0.1
gateway/ws: closed before connect cause=handshake-timeout, handshakeMs=3000, durationMs=8874

Code Example

gateway connect failed: Error: gateway closed (1000): 
Error: gateway closed (1000 normal closure): no close reason

---

gateway/ws: handshake timeout conn=<id> remote=127.0.0.1
gateway/ws: closed before connect cause=handshake-timeout, handshakeMs=3000, durationMs=8874

RAW_BUFFERClick to expand / collapse

Summary

openclaw cron run <job-id> --expect-final --timeout 120000 fails with:

gateway connect failed: Error: gateway closed (1000): 
Error: gateway closed (1000 normal closure): no close reason

Root Cause

Timeline from logs:

CLI process starts, begins loading plugins
Gateway detects new WebSocket connection, starts 3s handshake timer
At ~3s: gateway logs handshake timeout conn=<id> remote=127.0.0.1
At ~8s: CLI finishes plugin init, but connection already closed
CLI receives gateway closed (1000): no close reason

Gateway log evidence:

gateway/ws: handshake timeout conn=<id> remote=127.0.0.1
gateway/ws: closed before connect cause=handshake-timeout, handshakeMs=3000, durationMs=8874

Current Behavior

DEFAULT_HANDSHAKE_TIMEOUT_MS is hardcoded to 3000
OPENCLAW_TEST_HANDSHAKE_TIMEOUT_MS env var exists but is gated behind process.env.VITEST, so it only works in test environments
No config file option (e.g., gateway.handshakeTimeoutMs) exists
The CLI loads all discovered plugins before completing the WebSocket handshake

Impact

Only affects CLI-initiated commands (openclaw cron run, etc.)
Scheduled cron execution via the internal scheduler is not affected (runs inside the gateway process)
More plugins installed = higher chance of hitting this timeout
Environments with non-bundled plugins (custom extensions) are particularly affected

Suggested Fix (any of these would help)

Expose a config option like gateway.handshakeTimeoutMs (or gateway.ws.handshakeTimeoutMs) to allow users to increase the timeout
Increase the default — 3s is tight when multiple plugins need to initialize; 10-15s would be safer
Reorder CLI startup — complete the WebSocket handshake first, then load plugins (best fix, but likely more invasive)
Ungating the env var — allow OPENCLAW_TEST_HANDSHAKE_TIMEOUT_MS to work outside of VITEST as a quick escape hatch

Environment

OpenClaw version: 2026.3.13
Node: v22.22.0
OS: Linux (x64)
Non-bundled plugins: 6 (including custom extensions)

Reproduction

Install several non-bundled plugins/extensions
Run openclaw cron run <any-job-id> --expect-final --timeout 120000
Observe handshake timeout if plugin init exceeds 3s

extent analysis

Fix Plan

To address the handshake timeout issue, we'll implement a config option to increase the timeout. Here are the steps:

Introduce a new config option gateway.handshakeTimeoutMs with a default value of 10 seconds.
Update the WebSocket handshake timeout to use the new config option.
Allow users to override the default timeout via a config file or environment variable.

Example Code

// config.js
const config = {
  // ... other config options ...
  gateway: {
    handshakeTimeoutMs: 10000, // 10 seconds
  },
};

module.exports = config;

// websocket.js
const config = require('./config');

const DEFAULT_HANDSHAKE_TIMEOUT_MS = config.gateway.handshakeTimeoutMs;

// Use the new default timeout for WebSocket handshake
const ws = new WebSocket('ws://example.com', {
  handshakeTimeout: DEFAULT_HANDSHAKE_TIMEOUT_MS,
});

Verification

To verify the fix, run the following command with multiple non-bundled plugins installed:

openclaw cron run <any-job-id> --expect-final --timeout 120000

If the handshake timeout issue is resolved, the command should complete successfully without errors.

Extra Tips

Consider increasing the default timeout to 15 seconds or more, depending on the specific use case and plugin initialization times.
If using a config file, ensure that the gateway.handshakeTimeoutMs option is properly configured and overridden when necessary.
For environments with custom extensions, monitor the handshake timeout and adjust the config option as needed to prevent issues.

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

#autograd error #model save/load #optimization #mixed precision #training loop

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Data

Security

Network

Code

UI/UX

Text

System

Multimedia

Protocol

API

Engineering

openclaw - 💡(How to fix) Fix CLI handshake timeout when plugins take >3s to load [1 participants]

Recommended Tools

GitHub issue graph ai analysis

Error Message

Root Cause

Code Example

Summary

Root Cause

Current Behavior

Impact

Suggested Fix (any of these would help)

Environment

Reproduction

extent analysis

Fix Plan

Example Code

Verification

Extra Tips

Still need to ship something?

TRENDING

openclaw - 💡(How to fix) Fix CLI handshake timeout when plugins take >3s to load [1 participants]

Recommended Tools

GitHub issue graph ai analysis

Error Message

Root Cause

Code Example

Summary

Root Cause

Current Behavior

Impact

Suggested Fix (any of these would help)

Environment

Reproduction

extent analysis

Fix Plan

Example Code

Verification

Extra Tips

Still need to ship something?

RELATED_DISCOVERY

TRENDING