Summary

Hi OpenClaw team 👋

Since one of the last 1-2 updates, openclaw logs --follow no longer works reliably for watching the gateway log over a longer period of time.

It now disconnects repeatedly with a gateway error. Because of that, it is currently not really possible to keep the log open and monitor what is happening live. I have to restart the command again and again.

What happens

When I run:

openclaw logs --follow

it often exits with:

gateway connect failed: Error: gateway closed (1000):
Gateway not reachable. Is it running and accessible?
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /root/.openclaw/openclaw.json
Bind: loopback
Hint: run `openclaw doctor`.

Sometimes before that I also see:

Log tail truncated (increase --max-bytes).

Why this is confusing

Right after openclaw logs --follow says the gateway is not reachable, openclaw gateway status says the gateway is actually running and reachable:

Runtime: running
Connectivity probe: ok
Listening: 127.0.0.1:18789
Capability: admin-capable

So it looks like the gateway itself is still alive, but the logs --follow command loses the connection or gives up too easily.

Expected behavior

openclaw logs --follow should keep running and continue following the log, so it can be used for live monitoring.

If the log grows too quickly or the websocket has a short hiccup, it would be helpful if the command could recover or retry instead of exiting completely.

Actual behavior

openclaw logs --follow exits repeatedly. This makes it impossible to keep the log open for continuous debugging or monitoring.

Environment

• OpenClaw: 2026.4.26 (be8c246)
• OS: Ubuntu / Linux
• Install method: npm
• Gateway bind: loopback
• Gateway target: ws://127.0.0.1:18789
• Gateway port: 18789
• Service: systemd user service

Additional notes

openclaw version currently cannot be used on this setup because the version CLI plugin is excluded by plugins.allow:

The `openclaw version` command is unavailable because `plugins.allow` excludes "version".

That may be unrelated, but I wanted to include it in case the CLI plugin loading / allowlist behavior is relevant.

Related issues / PRs

This seems related to, but not fully covered by:

• fix(logs): only report rotation when the log file actually shrank #74252 — fixes misleading reset/rotation behavior when the log grows quickly
• fix(cli): reuse websocket for logs --follow #56475 — proposes reusing/persisting the websocket for logs --follow
• [Bug]: 4.26 version cutdown connection to local model in few minites #74078 — reports gateway unreachable symptoms on 2026.4.26
• [2026.4.26] Gateway main thread stalls under orchestration load; /readyz timeouts and reload deferred behind active runs #73467 — reports gateway stalls / timeouts on 2026.4.26

Thanks for looking into this 🙏