fix: stabilize tray pairing and reconnect behavior

[andyeskridge]

Summary

This updates the Windows tray node pairing flow to match current OpenClaw gateway behavior and fixes reconnect recovery after gateway restarts.

Why

The tray previously assumed a node was only paired if hello-ok returned auth.deviceToken and that token was persisted locally.

In practice, current gateway behavior for Windows WS nodes looks like this:

• unapproved device -> NOT_PAIRED
• approved device -> hello-ok
• node commands work normally after approval
• auth.deviceToken is not always returned
• That left the tray in incorrect states like false Pending, false Unknown, and failed reconnect recovery after gateway restarts.

Changes

• treat NOT_PAIRED as a real pairing-needed state instead of a generic registration error
• only show pending approval when the gateway explicitly indicates pairing is required
• treat an approved hello-ok as paired even when auth.deviceToken is absent
• fix websocket reconnect so the tray keeps retrying until the gateway is back
• suppress repeated pairing/connect notifications and duplicate activity noise on routine reconnects
• tighten pairing event matching so node pairing events use the actual node identity when available

Validation

Tested locally against a real gateway:

• fresh tray state enters Pending on NOT_PAIRED
• approving the device in OpenClaw transitions the node to Connected
• node requests succeed after approval (system.notify verified)
• gateway restart disconnects the tray, retries through startup errors, and reconnects automatically

[Copilot]

Pull request overview

Stabilizes the Windows tray “node mode” pairing state machine and improves reconnect recovery after gateway restarts, aligning tray behavior with current gateway responses (including NOT_PAIRED and hello-ok without auth.deviceToken).

Changes:

• Update tray pairing notifications to suppress duplicate Pending/Paired toasts/activity.
• Extend WindowsNodeClient to handle pairing-required errors, pairing events, and treat hello-ok as paired even without auth.deviceToken.
• Make WebSocket reconnect retry continuously with backoff until the gateway is reachable again.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
src/OpenClaw.Tray.WinUI/App.xaml.cs	Debounces pairing toasts/activity based on last observed pairing status.
src/OpenClaw.Shared/WindowsNodeClient.cs	Adds explicit pairing state tracking, handles NOT_PAIRED + pair events, and revises hello-ok handling.
src/OpenClaw.Shared/WebSocketClientBase.cs	Changes reconnect to loop with backoff until connected/disposed.

Comments suppressed due to low confidence (1)

src/OpenClaw.Shared/WindowsNodeClient.cs:575

• _pairingApprovedAwaitingReconnect is documented as “until the next successful reconnect”, but in the hello-ok path it is only cleared when auth.deviceToken is present. If the gateway approves and then reconnects without returning auth.deviceToken, this flag stays true indefinitely, causing incorrect state/logging on subsequent reconnects. Clear _pairingApprovedAwaitingReconnect after processing the first successful hello-ok post-approval (even when no device token is returned).

            else if (_pairingApprovedAwaitingReconnect)
            {
                _logger.Info("hello-ok arrived after pairing approval without auth.deviceToken; keeping local state paired.");
            }

            _logger.Info($"Node registered successfully! ID: {_nodeId ?? _deviceIdentity.DeviceId.Substring(0, 16)}");
            _logger.Info($"[NODE] hello-ok auth present={hasAuthPayload}, receivedDeviceToken={receivedDeviceToken}, storedDeviceToken={!string.IsNullOrEmpty(_deviceIdentity.DeviceToken)}, pendingApproval={_isPendingApproval}, awaitingReconnect={_pairingApprovedAwaitingReconnect}");
            
            _isPendingApproval = false;
            _isPaired = true;
            _logger.Info(string.IsNullOrEmpty(_deviceIdentity.DeviceToken)
                ? "Gateway accepted the node without returning a device token; treating this device as paired"
                : "Already paired with stored device token");

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The PairingStatusChanged event emitted on hello-ok uses the message "Pairing approved!" even when approval may have happened previously (e.g., device already approved on the gateway but no auth.deviceToken is returned). This is likely to mislead users because hello-ok indicates successful registration, not necessarily a new approval action. Consider using a more neutral message (e.g., "Node connected" / "Node registration accepted") or only using "approved" wording when a pairing approval event was actually observed.

This issue also appears on line 563 of the same file.

See below for a potential fix:

                var pairingMessage = (receivedDeviceToken || _pairingApprovedAwaitingReconnect)
                    ? "Pairing approved!"
                    : "Node registration accepted";
                PairingStatusChanged?.Invoke(this, new PairingStatusEventArgs(
                    PairingStatus.Paired,
                    _deviceIdentity.DeviceId,
                    pairingMessage));

[Copilot]

Pairing toast/activity suppression only keys off the previous status, not the device identity. If the device identity changes during the app session (e.g., device key regenerated) and the new device immediately enters Pending/Paired, the toast could be incorrectly suppressed because previousStatus matches. Track the last deviceId along with status (or reset _lastNodePairingStatus when args.DeviceId changes).

[Copilot]

ReconnectWithBackoffAsync now raises ConnectionStatus.Connecting on every retry iteration. In the tray app, OnNodeStatusChanged logs recent activity for every status change, so this can create noisy repeated "Node mode Connecting" entries while the gateway is down. Consider deduping/only emitting Connecting when transitioning from a non-connecting state, or moving the attempt counter into logs without raising a new status event each loop.

See below for a potential fix:

        // Only emit "Connecting" once when entering the reconnect loop to avoid noisy duplicates.
        RaiseStatusChanged(ConnectionStatus.Connecting);

        while (!_disposed)
        {
            var delay = BackoffMs[Math.Min(_reconnectAttempts, BackoffMs.Length - 1)];
            _reconnectAttempts++;
            _logger.Warn($"{ClientRole} reconnecting in {delay}ms (attempt {_reconnectAttempts})");

[Copilot]

The new pairing state machine (handling NOT_PAIRED, node/device.pair.* events, and hello-ok without auth.deviceToken) isn’t covered by unit tests. There are existing WindowsNodeClientTests, but they only validate URL normalization; adding tests that feed representative JSON into ProcessMessageAsync/handlers would help prevent regressions in reconnect + pairing behavior.