Bug type

Behavior bug (incorrect output/state without crash)

Summary

On OpenClaw v2026.3.12, Control UI still rejects cross-device LAN access with device identity required even when gateway.controlUi.dangerouslyDisableDeviceAuth: true is enabled and a valid gateway token is supplied.

In other words, for a local/LAN HTTP deployment where the intent is "any device with the correct token can enter", the current release still enforces device identity during the WebSocket handshake.

Steps to reproduce

1. Run OpenClaw gateway on a LAN host
2. Configure Control UI-related auth to allow token-based access over HTTP/LAN, including:
   • gateway.controlUi.dangerouslyDisableDeviceAuth: true
   • gateway.controlUi.allowInsecureAuth: true
3. Open the Control UI from another device on the same LAN using the host LAN IP, e.g.:
   • http://<lan-ip>:18789/#token=<valid-token>
4. Observe that the UI page loads, but the WebSocket handshake fails and the UI cannot connect

Expected behavior

With gateway.controlUi.dangerouslyDisableDeviceAuth: true, a browser on another LAN device that supplies a valid token should be allowed to connect without requiring device identity / pairing.

Actual behavior

The UI cannot connect. Gateway logs show repeated handshake failures with:

• cause: "device-required"
• reason: "device identity required"

OpenClaw version

2026.3.12

Operating system

Ubuntu 24.04

Install method

npm/global install on host

Model

cli-proxy/gpt-5.4

Provider / routing chain

openclaw -> proxy OpenAI-compatible endpoint

Additional provider/model setup details

Not model-specific. This appears to be a gateway / Control UI auth-handshake issue.

Relevant config (redacted)

{
  gateway: {
    port: 18789,
    mode: "local",
    bind: "lan",
    auth: {
      mode: "token"
    },
    controlUi: {
      allowInsecureAuth: true,
      dangerouslyDisableDeviceAuth: true,
      dangerouslyAllowHostHeaderOriginFallback: true
    }
  }
}

Logs, screenshots, and evidence

Gateway logs from real failed attempts:

warn gateway/ws {"cause":"device-required","handshake":"failed", ... }
closed before connect code=1008 reason=device identity required

Example full log shape:

warn gateway/ws {"subsystem":"gateway/ws"} security warning: websocket origin accepted via Host-header fallback conn=... host=192.168.10.10:18789 origin=http://192.168.10.10:18789
warn gateway {"subsystem":"gateway"} security metric: gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback accepted a websocket connect request
warn gateway/ws {"subsystem":"gateway/ws"} {"cause":"device-required","handshake":"failed","durationMs":13,"lastFrameType":"req","lastFrameMethod":"connect","host":"192.168.10.10:18789","origin":"http://192.168.10.10:18789","client":"openclaw-control-ui","mode":"webchat","version":"2026.3.12"} closed before connect code=1008 reason=device identity required

Also confirmed separately:

• The HTTP endpoint itself is reachable (HTTP/1.1 200 OK)
• The failure happens specifically at the WebSocket / auth handshake stage
• The problem reproduces across repeated attempts from another LAN device

Impact and severity

High for LAN/self-hosted setups that intentionally want token-only Control UI access across devices without pairing.

This makes the current release unusable for that access mode even though the config suggests it should be supported.

Additional information

This looks related to the recent regressions / fixes already discussed in:

• [Bug]: dangerouslyDisableDeviceAuth not working in v2026.3.11 #43909
• [Bug]: dangerouslyDisableDeviceAuth: true ignored in 2026.3.11 — Control UI rejects HTTP connections with "device identity required" #44485
• Bug: dangerouslyDisableDeviceAuth not applied in WebSocket validation (Control UI) #41539
• dangerouslyDisableDeviceAuth does not fully bypass device identity check when sharedAuthOk is false #43164
• [Bug]: Control UI fails to authenticate over plain HTTP (insecure context) #44864
• PRs fix(gateway): honor dangerouslyDisableDeviceAuth in evaluateMissingDeviceIdentity #44034, fix(gateway): honor dangerouslyDisableDeviceAuth regardless of sharedAuthOk #44486, fix(ui): send token/password auth in Control UI insecure contexts #44865

However, on v2026.3.12 the real-world behavior is still reproducible in this LAN/plain-HTTP scenario.

Possibly either:

1. the gateway-side bypass is still not fully applied in this path, and/or
2. the Control UI still fails to send/propagate explicit token auth correctly in insecure/LAN contexts.