Windows Tray App does not auto-reconnect after Gateway restart

[iliujiannan]

Bug Report: Windows Tray App Does Not Auto-Reconnect After Gateway Restart

Description

When the OpenClaw Gateway restarts, the Windows Tray App (Node Mode) does not automatically reconnect. The node stays in a disconnected state indefinitely and requires manual intervention to reconnect.

This is inconsistent with the CLI node (openclaw node run), which does attempt to reconnect automatically as shown in its logs:

Node reconnecting in 1000ms (attempt 1)

Steps to Reproduce

1. Install OpenClaw Windows Tray App and enable Node Mode in Settings → Advanced (Experimental)
2. Confirm node is connected and visible in openclaw nodes status on the Gateway
3. Restart the Gateway (openclaw gateway restart or service restart)
4. Observe the Windows Tray App — node remains disconnected and does not reconnect

Expected Behavior

The Windows Tray App should automatically detect the Gateway reconnection and re-establish the node connection, similar to how the CLI node handles reconnection.

Actual Behavior

The node stays disconnected after Gateway restart. Manual workaround required:

• Toggle Node Mode off and on again in the app settings

Environment

• OpenClaw Tray App version: 0.4.7
• Windows version: Windows 11 x64
• Gateway connection: Remote Gateway over WSS (Nginx TLS reverse proxy)
• Node Mode: Enabled via Settings → Advanced (Experimental)

Logs

After Gateway restart, the app shows:

[INFO] Node status changed: Disconnected
[INFO] Node status: Disconnected

No reconnection attempts are logged afterward.

Workaround

Manually toggle Node Mode off → wait 2-3 seconds → toggle back on.

Additional Context

The CLI node (openclaw node run / node install) handles this correctly with automatic retry logic. It would be great if the Tray App implemented the same behavior.

[github-actions]

🤖 This is an automated response from Repo Assist.

Thanks for the detailed report, @iliujiannan — the steps to reproduce and the log snippet are really helpful.

What the code does

WindowsNodeClient inherits from WebSocketClientBase, which has an auto-reconnect loop (ReconnectWithBackoffAsync) that runs after an unexpected disconnect. When the Gateway closes the WebSocket (either with a clean close frame or a premature TCP drop), the listen loop detects the close and — as long as the client was not explicitly disposed — schedules exponential-backoff reconnect attempts. You should see log lines like:

[WARN] node reconnecting in 1000ms (attempt 1)
[WARN] node reconnecting in 2000ms (attempt 2)
...

If those lines are not appearing in your logs, the reconnect is not being triggered. The most likely causes:

Cause 1 — Version predates the full reconnect loop

The "loops until connected" backoff was a relatively recent improvement. Version 0.4.7 may have had a single-retry path that silently failed on the first attempt rather than looping. Upgrading to the latest release is the first thing to try.

Cause 2 — TLS/Nginx close sequence produces an unrecognised error code

The listen loop catches WebSocketException with WebSocketErrorCode == ConnectionClosedPrematurely. When Nginx is in the path, a Gateway restart might produce a different close sequence (e.g., a TLS alert before the TCP RST). A WebSocketException with a different error code falls through to the general catch (Exception ex) handler, which still triggers reconnect — but if a different exception type is thrown it might suppress reconnect unexpectedly. Adding Debug-level logging to your build would confirm which path is taken.

Cause 3 — Settings toggle triggers a full dispose

If anything in the app calls NodeService.DisconnectAsync() (which calls Dispose() on the underlying client) in response to the disconnect event, _disposed is set to true and the reconnect guard if (!_disposed) blocks reconnect permanently until the service is recreated. This is the correct behaviour when the user intentionally disables Node Mode, but should not fire on an unexpected drop.

Suggested diagnostics

If you can reproduce with the latest version and still see no reconnect attempts:

1. Check whether [WARN] node reconnecting in ever appears in the log
2. Note the exact exception type and WebSocketErrorCode if visible (enable debug logging if possible)
3. Check whether Node status changed: Disconnected is followed by any Connecting or reconnecting message

Feel free to share the relevant log section and I can help narrow it down further.

Generated by Repo Assist · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@cbb46ab386962aa371045839fc9998ee4e97ca64