Molty v0.6.0 Node Mode: WebSocket handshake fails with code 1006 on Gateway v2026.5.28 (WSL2)

[schlesimu]

Bug: Device token mismatch + code 1006 preventing node mode connection

Environment

• Gateway: OpenClaw 2026.5.28 (WSL2 Ubuntu, loopback, port 18789)
• Molty: OpenClaw Windows Tray v0.6.0 (Windows 11)
• Auth mode: token (shared gateway token)

Summary

Molty operator connection (Quick Send) works fine, but Node Mode never connects. The node WebSocket handshake consistently fails with code 1006.

Steps to Reproduce

1. Install Gateway v2026.5.28 on WSL2 Ubuntu
2. Install Molty v0.6.0 on Windows 11
3. Connect to ws://127.0.0.1:18789 with shared token
4. Enable Node Mode
5. Approve device pairing requests
6. Node WebSocket always closes with code 1006

Observed Behavior

1. Device re-approval loop: Every Molty restart → device_token_mismatch
2. Node handshake fails: [ws] closed before connect code=1006
3. allowCommands not recognized: Gateway returns "node did not declare any supported commands" despite Molty declaring 25 commands

Additional Bug: TTS Crash

When VoiceTtsEnabled=true, Molty crashes:
System.DllNotFoundException: Unable to load DLL 'sherpa-onnx-c-api' (0x8007045A)

[clawsweeper]

Thanks for the context here. I did a careful shell check against current main, and this is already implemented.

Close as implemented on current main: the Windows-client Node Mode credential/capability failures are covered by the merged connection hardening work, and the bundled SherpaOnnx TTS crash is covered by the merged native-loader/finalizer fix.

I found the merged PR that appears to have closed this: #745: Fix SherpaOnnx finalizer crash with DllNotFoundException.

So I’m closing this as already implemented rather than keeping a duplicate issue open.

Review details

Best possible solution:

Keep the current main connection and TTS fixes, and leave remote gateway-side node scope/rotation follow-up to #710.

Do we have a high-confidence way to reproduce the issue?

Yes for the client-owned paths: the report has concrete WSL2 steps, current source/tests cover the fixed setup/connect/capability path, and the merged connection PR reported real WSL E2E validation. I did not rerun a live Gateway v2026.5.28 tray repro in this read-only review.

Is this the best way to solve the issue?

Yes. The durable fix is the current main split between connection/pairing hardening and the narrow SherpaOnnx native-load/finalizer mitigation; remote gateway scope behavior is better handled in the separate open remote-gateway issue.

Security review:

Security review: No patch is under review; this non-PR triage is closed based on implemented source and history evidence.

AGENTS.md: found and applied where relevant.

What I checked:

• AGENTS.md policy read and applied: Repository guidance on GatewayConnectionManager ownership, credential precedence, per-gateway identity storage, and Node/MCP mode shaped the review of this connection/pairing issue. (AGENTS.md:28, 260fb90c6dc7)
• Connection source now handles stale operator device-token recovery: Current main detects device-token mismatch, clears the stale operator token when bootstrap recovery material exists, and reconnects with bootstrap instead of staying in the re-approval loop. (src/OpenClaw.Connection/GatewayConnectionManager.cs:756, 260fb90c6dc7)
• Bootstrap cleanup waits for durable role tokens: Current main retains bootstrap credentials until both operator and node role tokens are durably readable, matching the paired-device recovery path described in the issue discussion. (src/OpenClaw.Connection/GatewayConnectionManager.cs:857, 260fb90c6dc7)
• Node capability binding happens before handshake: NodeConnector fires ClientCreated before ConnectAsync so NodeService can register caps/commands before the outbound node connect frame, and aborts before handshake if that binding fails. (src/OpenClaw.Connection/NodeConnector.cs:127, 260fb90c6dc7)
• Current E2E coverage asserts connected node capabilities: The setup/connect E2E test verifies the tray reaches connected operator and node state and that the Windows node reports the expected capabilities and commands instead of caps=0/cmds=0. (tests/OpenClaw.E2ETests/Setup/SetupAndConnectTests.cs:34, 260fb90c6dc7)
• TTS native DLL crash source is mitigated: Current main explicitly loads the Sherpa native library before constructing OfflineTts and suppresses the OfflineTts finalizer before disposal, covering the reported sherpa-onnx-c-api crash path. (src/OpenClaw.Tray.WinUI/Services/TextToSpeech/PiperTextToSpeechClient.cs:61, 260fb90c6dc7)

Likely related people:

• ranjeshj: Authored the merged connection hardening PR, and git history ties current role-token persistence, bootstrap cleanup, stale-client guards, and node handshake hardening to that work. (role: recent connection fix contributor; confidence: high; commits: ea36b12f9e4c; files: src/OpenClaw.Connection/GatewayConnectionManager.cs, src/OpenClaw.Connection/NodeConnector.cs, src/OpenClaw.Shared/OpenClawGatewayClient.cs)
• williamwwm: Authored the merged SherpaOnnx finalizer/native-load fix that covers the TTS crash portion of the report. (role: recent TTS crash-fix contributor; confidence: high; commits: aff45d0e6aea; files: src/OpenClaw.Tray.WinUI/Services/TextToSpeech/PiperTextToSpeechClient.cs, tests/OpenClaw.Tray.Tests/PiperTextToSpeechClientContractTests.cs)
• Régis Brid: Shortlog and history show repeated earlier work across the connection/client and audio/TTS capability surfaces involved in the original report. (role: feature-history contributor; confidence: medium; commits: b0ba9affa25d, 5505a85da7df, 753828f63e96; files: src/OpenClaw.Connection/GatewayConnectionManager.cs, src/OpenClaw.Shared/OpenClawGatewayClient.cs, src/OpenClaw.Tray.WinUI/Services/NodeService.cs)

Codex review notes: model internal, reasoning high; reviewed against 260fb90c6dc7; fix evidence: merged PR #745, commit aff45d0e6aea, main fix timestamp 2026-06-15T04:34:11-07:00.

[ranjeshj]

Update from #741:

This PR should address several Windows-client-side causes called out here:

• stale operator device-token mismatch recovery now clears the stale operator token and reconnects with bootstrap when bootstrap recovery material still exists;
• node capability binding now aborts before the node handshake if capabilities cannot be registered, preventing the gateway from accepting a caps=0 / cmds=0 node session;
• node connection/status/pairing events are guarded against stale replaced clients mutating the current connection state;
• setup-code/bootstrap token cleanup now waits until both operator and node role tokens are durably readable.

Still pending / not covered by #741:

• the TTS sherpa-onnx-c-api DLL crash is unrelated to connection/pairing and is not fixed here;
• any gateway-side behavior not reproducible from the Windows client remains outside this PR.

Validation on #741 included full real WSL E2E passing: OPENCLAW_RUN_E2E=1 dotnet test ./tests/OpenClaw.E2ETests/OpenClaw.E2ETests.csproj -r win-arm64 --no-restore (17/17).

[github-actions]

🤖 This is an automated response from Repo Assist.

Thanks for the detailed report. Two separate efforts are now underway to address the issues described here:

1. Connection / pairing / capability-registration fixes → PR #741 ("Harden gateway connection and pairing flows"):

• Operator shared-token connect now requests operator.pairing + admin so pairing-management endpoints are reachable
• Node-pair / device-pair approval now awaits gateway responses instead of treating a sent frame as success
• Node capability binding aborts before the handshake if capabilities cannot be registered, preventing caps=0/cmds=0 sessions
• Stale replaced-client events are guarded against mutating connection state
• Bootstrap cleanup waits until both operator and node role tokens are durably readable

2. SherpaOnnx TTS crash → PR #745 ("Fix SherpaOnnx finalizer crash with DllNotFoundException"):

• Catches DllNotFoundException in PiperTextToSpeechClient constructor → TTS silently disabled rather than crashing
• Adds GC.SuppressFinalize after dispose to prevent the finalizer from invoking native DLL cleanup when the DLL was never loaded

Still pending / not covered by either PR:

• Gateway-side token scope and devices rotate --role node behaviour (outside this repo)
• A live remote-gateway repro to fully validate the fixes in Harden gateway connection and pairing flows #741

If you can test against a branch build once either PR is ready for testing, your feedback would be very helpful.

Generated by 🌈 Repo Assist, see workflow run. Learn more.

Add this agentic workflows to your repo

To install this agentic workflow, run

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