Can I work around this without upgrading?

There is no simple configuration workaround for this regression. You must apply the fix provided in the latest main build to restore the auth header transmission logic.

Is it safe to use dangerouslyDisableDeviceAuth?

Only on trusted LAN segments. It bypasses specific cryptographic handshake requirements, so ensure your network is isolated and protected.

Does this affect HTTPS connections?

No. This issue is specific to insecure (HTTP) contexts where the browser prevents standard secure identity handshakes.

Resolving 'device identity required' in OpenClaw LAN Mode

TL;DR — Quick Fix

The Control UI fails to pass auth tokens over insecure HTTP because it incorrectly skips authentication logic; upgrade to the latest build to include the corrected auth header transmission.

Run Diagnostics

Next Step

Fix now, then reduce repeat incidents

If this issue keeps coming back, validate your setup in Doctor first, then harden your config.

Open Doctor Harden Config

Error Signal

device identity required

What's Happening

You're trying to connect to your OpenClaw gateway over LAN using HTTP, but despite setting allowInsecureAuth and dangerouslyDisableDeviceAuth, you're hitting a wall. The UI throws a "device identity required" error because it stops sending your auth token in the request headers.

The Fix

Upgrade your OpenClaw instance to the latest version. A fix has been merged into the main branch that explicitly forces the gateway to attach authToken or authPassword from your connection options, even when the browser environment is detected as insecure (non-HTTPS).

If you are running the gateway in Docker, simply pull the latest image:

docker pull openclaw/openclaw:latest
docker-compose up -d --force-recreate

Once the service restarts, the Control UI will correctly inject the auth token into the connect payload, bypassing the requirement for device identity verification that triggered the error.

Why This Occurs

This is a regression in how the GatewayBrowserClient handles authentication. Previously, the logic in ui/src/ui/gateway.ts only triggered the selectConnectAuth function if the connection was secure (isSecureContext).

When running over LAN via HTTP, the browser detects an insecure context. The previous code path simply skipped selecting any authentication method, meaning your connect request arrived at the gateway with an empty params.auth object. The gateway then rejected the request because it didn't find the expected identity headers, even though you explicitly configured it to allow insecure auth.

Prevention

Always ensure your gateway configuration is matched by your network environment. While dangerouslyDisableDeviceAuth is a powerful tool for LAN debugging, it does not bypass the need for a token if your auth.mode is set to token. Verify these settings in your gateway.yaml:

gateway:
  auth:
    mode: "token"
    token: "YOUR_SECRET_TOKEN"
  controlUi:
    allowInsecureAuth: true
    dangerouslyDisableDeviceAuth: true

If you still face issues, inspect your browser's network tab (F12) and check the connect WebSocket frame to ensure the payload includes your auth token. If it's missing, you are likely still on a version prior to the fix.

Last Updated: March 2026

Did this guide solve your problem?