Problem
When running openclaw logs --follow, any transient gateway WebSocket disconnect (e.g., gateway restart, temporary connection drop) causes the CLI to immediately process.exit(1), terminating the log tail session.
This is particularly annoying during gateway restarts or when brief connectivity hiccups occur — the user has to manually re-run the command.
Root Cause Analysis
Looking at logs-cli.ts (v2026.4.26, logs-cli-BwVDUQL4.js), the fetch loop in logs --follow works as a polling loop calling callGatewayFromCli("logs.tail"):
while (true) {
try {
payload = await fetchLogs(opts, cursor, showProgress);
} catch (err) {
await emitGatewayError(err, opts, jsonMode ? "json" : "text", rich, emitJsonLine, errorLine);
process.exit(1); // ← exits immediately, no retry
return;
}
// ... process lines ...
await setTimeout(interval);
}
The only fallback path is shouldUseLocalLogsFallback(), which only triggers for pairing-required messages (readConnectPairingRequiredMessage). All other errors (connection refused, network error, WebSocket close, etc.) are treated as fatal.
Expected Behavior
openclaw logs --follow should:
- Auto-reconnect on transient errors (connection refused, network unreachable, WebSocket closed)
- Log a warning about the disconnect (e.g.,
[logs] gateway disconnected, reconnecting...)
- Retry with exponential backoff (similar to the gateway client reconnect logic)
- Only exit on non-recoverable errors (auth failure, wrong URL, etc.)
- Optionally support
--max-retries or --retry-interval flags
Reproduction
- Run
openclaw logs --follow in one terminal
- Restart the gateway:
openclaw gateway restart
- Observe:
openclaw logs --follow exits with gateway connect failed error instead of reconnecting
Environment
- OpenClaw version: 2026.4.26 (be8c246)
- OS: Linux 6.16.4
- Gateway bind: loopback (127.0.0.1:18789)
Related
The gateway client already has sophisticated reconnect/backoff logic (seen in client-Dh94CUDv.js), but the CLI logs command does not reuse or replicate it.
Problem
When running
openclaw logs --follow, any transient gateway WebSocket disconnect (e.g., gateway restart, temporary connection drop) causes the CLI to immediatelyprocess.exit(1), terminating the log tail session.This is particularly annoying during gateway restarts or when brief connectivity hiccups occur — the user has to manually re-run the command.
Root Cause Analysis
Looking at
logs-cli.ts(v2026.4.26,logs-cli-BwVDUQL4.js), the fetch loop inlogs --followworks as a polling loop callingcallGatewayFromCli("logs.tail"):The only fallback path is
shouldUseLocalLogsFallback(), which only triggers for pairing-required messages (readConnectPairingRequiredMessage). All other errors (connection refused, network error, WebSocket close, etc.) are treated as fatal.Expected Behavior
openclaw logs --followshould:[logs] gateway disconnected, reconnecting...)--max-retriesor--retry-intervalflagsReproduction
openclaw logs --followin one terminalopenclaw gateway restartopenclaw logs --followexits withgateway connect failederror instead of reconnectingEnvironment
Related
The gateway client already has sophisticated reconnect/backoff logic (seen in
client-Dh94CUDv.js), but the CLI logs command does not reuse or replicate it.