Bug Report

Version: OpenClaw 2026.3.8 (3caab92)
OS: Linux (Ubuntu)

Description

The gateway.controlUi.dangerouslyDisableDeviceAuth flag is loaded and appears in security warnings, but is not applied during WebSocket connection validation. Control UI connections are still rejected with "device identity required" despite the flag being set to true.

Configuration

{
  "gateway": {
    "controlUi": {
      "dangerouslyDisableDeviceAuth": true,
      "allowInsecureAuth": true,
      "allowedOrigins": ["https://192.168.x.x:18789", "http://localhost:18789"]
    },
    "tls": {
      "enabled": true
    },
    "bind": "lan"
  }
}

Evidence

1. Config is loaded correctly (from gateway startup logs):

gateway security warning: dangerous config flags enabled: 
gateway.controlUi.allowInsecureAuth=true, 
gateway.controlUi.dangerouslyDisableDeviceAuth=true

2. But WebSocket validation still rejects connections (from logs):

[ws] closed before connect conn=xxx remote=192.168.x.x 
origin=https://192.168.x.x:18789 host=192.168.x.x:18789 
code=1008 reason=device identity required

Expected Behavior

When dangerouslyDisableDeviceAuth: true is set, Control UI should accept connections with only token authentication, without requiring device identity/pairing.

Actual Behavior

The flag is read and logged in security warnings, but the WebSocket validation logic continues to enforce device identity requirements.

Reproduction Steps

1. Set gateway.controlUi.dangerouslyDisableDeviceAuth: true in config
2. Restart gateway
3. Attempt to connect from Control UI (any device/browser)
4. Connection fails with "device identity required"

Workaround

None found. Only localhost (127.0.0.1) connections work, but those fail for other reasons (cert issues).

Impact

Control UI is completely inaccessible from LAN/remote devices, making the dangerouslyDisableDeviceAuth flag non-functional for its intended break-glass purpose.