Gateway connection fails: device identity required (OpenClaw 2026.3.x)

[rajsundesha]

Bug Description

Claw3D v0.1.0 cannot connect to OpenClaw gateway 2026.3.11. The gateway rejects the WebSocket connection.

Error

Gateway closed (1012): upstream closed

Gateway Logs

Two types of failures observed:

1. Without token: cause: "device-required" — gateway expects device identity (key pair + signature), Claw3D sends client: "openclaw-control-ui" without device auth
2. With token: cause: "unauthorized", authReason: "token_mismatch" — even when the correct token from ~/.openclaw/openclaw.json is loaded by studio-settings.js

Environment

• OpenClaw: 2026.3.11
• Claw3D: 0.1.0
• Node: 22.21.0
• OS: macOS (Apple Silicon)
• Gateway bind: loopback (127.0.0.1:18789)

Steps to Reproduce

1. Have OpenClaw gateway running on port 18789
2. npm install && npm run dev
3. Open http://localhost:3000
4. Click "Connect" (with or without token)
5. Error: "Gateway closed (1012): upstream closed"

Root Cause

OpenClaw 2026.3.x gateway now requires device identity auth (public key + signature + nonce) for WebSocket connections. Claw3D gateway-proxy.js only supports token-based auth, which the gateway rejects with code=1008 reason=device identity required.

Expected Behavior

Claw3D should connect to the local gateway seamlessly, either by:

1. Implementing device auth protocol
2. Using the gateway's device pairing flow
3. Or being recognized as a trusted local client

[iamlukethedev]

@rajsundesha are you still experiencing this? Not sure if it was an Openclaw issue or Claw3D

[rgsharon]

@iamlukethedev Experiencing the same issue on OpenClaw 2026.3.28 with Claw3D v0.1.0 on macOS (Apple Silicon).

The root cause is confirmed: OpenClaw 2026.3.x gateways now require device identity auth (ed25519 key pair + signature + nonce challenge-response) for WebSocket connections. The Claw3D proxy in server/gateway-proxy.js only supports token-based auth, so the gateway rejects the connection with code=1008 reason=unauthorized: gateway token missing.

I've implemented a fix locally:

1. New server/device-auth.js — loads the existing device identity from ~/.openclaw/identity/device.json (or generates an ephemeral one), and provides signing helpers ported from nodeGatewayClient.ts.

2. Modified server/gateway-proxy.js — when the upstream gateway sends a connect.challenge event and the browser didn't provide its own device auth, the proxy now intercepts the challenge, signs the nonce with the device identity, and sends a new connect request with full device auth. The response is transparently rewritten back to the browser's original request ID. Browsers that provide their own device auth still pass through as before.

3. Updated tests — 9/9 passing, lint clean.

[pauloletsgo]

I'm having the same problem here, is there anything new about this issue? Thanks a lot!

[pauloletsgo]

I'm running OpenClaw 2026.5.12 on a VPS (Ubuntu 24, Node 22.22.2) with Claw3D v0.1.4.

Same issue as described here.

The gateway logs confirm the root cause: Claw3D sends minProtocol: 3, maxProtocol: 3 in the connect frame, but OpenClaw 2026.5.x requires protocol v4 (expectedProtocol: 4, minimumProbeProtocol: 4), so the connection is rejected immediately with code=1002 reason=protocol mismatch before any device auth challenge is even sent.

I tried two approaches:

• Patching server/gateway-proxy.js to intercept connect.challenge and sign with the device identity from ~/.openclaw/identity/device.json (based on rgsharon's suggestion above) — but the connection never reaches the challenge stage because the protocol version check fails first.

• Changing minProtocol and maxProtocol to 4 in src/lib/gateway/nodeGatewayClient.ts — the OpenClaw logs show a different behavior (timeout instead of immediate rejection), but the browser bundle cache makes it hard to confirm if the change is actually reaching the gateway.

Looking forward to an official fix. Happy to test a branch if one becomes available.