openclaw - ✅(Solved) Fix [Bug]: `dangerouslyDisableDeviceAuth: true` ignored in 2026.3.11 — Control UI rejects HTTP connections with "device identity required" [3 pull requests, 4 comments, 3 participants]

Q: Expected behavior

With `dangerouslyDisableDeviceAuth: true`, the gateway should skip device identity checks and allow browser connections over HTTP, as it did in 2026.3.8.

openclaw2026-03-13 00:38:54

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#44485•Fetched 2026-04-08 00:46:16

View on GitHub

Comments

Participants

Timeline

Reactions

Author

Participants

Timeline (top)

cross-referenced ×5commented ×4referenced ×3labeled ×2

After upgrading from 2026.3.8 to 2026.3.11, the Control UI rejects all browser connections over HTTP with code=1008 reason=device identity required, even with gateway.controlUi.dangerouslyDisableDeviceAuth: true. The flag worked correctly in 2026.3.8. Downgrading to 3.8 restores functionality.

Error Message

19:26:52 warn gateway/ws Loopback connection with non-local Host header. 19:26:52 warn gateway/ws {

Root Cause

Fix Action

Fix / Workaround

Run OpenClaw 2026.3.8 on a VPS behind a reverse proxy over HTTP (no HTTPS)
Set gateway.controlUi.dangerouslyDisableDeviceAuth: true in openclaw.json
Confirm Control UI works in browser — connects successfully
Upgrade to 2026.3.11: npm i -g [email protected] --prefix /usr/local
Restart gateway
Open Control UI in browser — fails with "device identity required"

Affected: All Control UI users on HTTP (no HTTPS) behind reverse proxies Severity: High (blocks workflow — Control UI completely inaccessible) Frequency: 100% repro on 2026.3.11 with HTTP + reverse proxy setup Consequence: Cannot access Control UI webchat after upgrading. Forces downgrade to 2026.3.8 to restore access. Blocks upgrade path for HTTP deployments.

Temporary workaround: Downgrade to 2026.3.8 by restoring from Hostinger skeleton: rm -rf /usr/local/lib/node_modules/openclaw cp -r /skeleton/.npm-global/lib/node_modules/openclaw /usr/local/lib/node_modules/openclaw

PR fix notes

PR #44486: fix(gateway): honor dangerouslyDisableDeviceAuth regardless of sharedAuthOk

Repository: openclaw/openclaw
Author: JasonOA888
State: open | merged: False
Link: https://github.com/openclaw/openclaw/pull/44486

Description (problem / solution / changelog)

Fixes #44485

Problem

After upgrading from 2026.3.8 to 2026.3.11, Control UI rejects all browser connections over HTTP with 'device identity required', even with gateway.controlUi.dangerouslyDisableDeviceAuth: true.

Root Cause

Commit 8d1481cb4 changed shouldSkipControlUiPairing() to require BOTH:

dangerouslyDisableDeviceAuth: true
sharedAuthOk: true

But on HTTP-only deployments, sharedAuthOk is often false (no token/password). This defeats the purpose of the flag.

Solution

When dangerouslyDisableDeviceAuth: true, skip pairing entirely regardless of sharedAuthOk.

Testing

Unit test updated
HTTP-only deployments can use Control UI again

Impact

Restores Control UI access for HTTP deployments behind reverse proxies.

Changed files

src/agents/pi-embedded-helpers/errors.ts (modified, +8/-0)
src/gateway/server/ws-connection/connect-policy.test.ts (modified, +4/-2)
src/gateway/server/ws-connection/connect-policy.ts (modified, +14/-2)

PR #45070: fix(gateway): always resolve device token for fallback auth during SPA navigation

Repository: openclaw/openclaw
Author: openperf
State: closed | merged: False
Link: https://github.com/openclaw/openclaw/pull/45070

Description (problem / solution / changelog)

Summary

The gateway connect-auth logic suppresses the stored device token whenever an explicit shared token or password is present. This means the auth.deviceToken field in the WebSocket connect frame is empty when the user connects via a dashboard token URL.

After SPA navigation or a page refresh strips the shared token from the URL hash, the next reconnect attempt has neither a shared token nor a device token, causing the gateway to reject with device identity required (close code 1008).

This PR fixes the root cause by resolving the stored device token independently of shared credentials, so auth.deviceToken is always populated when a device identity exists. The gateway server already supports deviceToken fallback when the shared token is absent or invalid (see the server auth matrix test "uses explicit auth.deviceToken fallback when shared token is wrong").

What changed

Production code (2 files)

File	Change
`src/gateway/client.ts`	Remove the `!(explicitGatewayToken \|\| authPassword)` guard from `resolvedDeviceToken` computation so the stored token is always resolved
`ui/src/ui/gateway.ts`	Same fix for the browser client; also include `deviceToken` in the `auth` object construction guard so the payload is built even when only a device token is available

Test code (2 files)

File	Change
`src/gateway/client.test.ts`	Update two tests to verify `deviceToken` is sent alongside shared token/password; add `deviceIdentity` to test fixtures (fixes the missing config gap flagged during review of #39639)
`ui/src/ui/gateway.node.test.ts`	Update browser-client test to verify `deviceToken` is sent alongside explicit shared auth

Root cause analysis

The issue was first reported in #39611 and traced to three interacting bugs by @NetZlash:

Bug 1 — resolvedDeviceToken guard in selectConnectAuth() discards the stored device token when any shared credential is present
Bug 2 — The browser client's auth object omits deviceToken when only a device token (no shared token/password) is available
Bug 3 — SPA navigation drops the URL hash token on same-tab reload

PR #40892 addressed Bug 3 via sessionStorage persistence, but Bugs 1 and 2 remain unfixed on main. This is confirmed by:

Users still reporting "device identity required" on v2026.3.12 (#39611 comments from @YIwanT, @ricardopera)
#39667 (device signature invalid) remaining open
#44485 (dangerouslyDisableDeviceAuth ignored in v2026.3.11) opened today
#44967 (LAN token-only access rejected on v2026.3.12) opened today

This PR fixes Bugs 1 and 2 at the gateway layer, complementing the UI-layer fix in #40892.

How to test

Start gateway with token auth: openclaw dashboard --no-open
Open the token URL in browser — Control UI connects
Navigate to Sessions → click a session → should stay connected (previously disconnected with 1008)
Refresh the page → should reconnect using the device token fallback
Open a new tab with the base URL (no token hash) → should still connect if device was previously paired

Related issues

Fixes #39667
Refs #39611, #44485, #44967
Supersedes #39639 (my earlier PR, closed as superseded by #40892 — this PR is scoped to the remaining gateway-layer bugs)

Changed files

src/gateway/client.test.ts (modified, +19/-5)
src/gateway/client.ts (modified, +9/-2)
ui/src/ui/gateway.node.test.ts (modified, +7/-2)
ui/src/ui/gateway.ts (modified, +8/-4)

PR #45088: fix(ui): keep shared auth on insecure control-ui connects

Repository: openclaw/openclaw
Author: velvet-shark
State: closed | merged: True
Link: https://github.com/openclaw/openclaw/pull/45088

Description (problem / solution / changelog)

Summary

Problem: plain-HTTP Control UI sessions behind LAN and reverse-proxy setups were dropping explicit shared token/password auth before the first WebSocket connect frame, so the gateway rejected them with device identity required.
Why it matters: this broke the intended allowInsecureAuth + dangerouslyDisableDeviceAuth token flow for self-hosted HTTP deployments even though same-tab refresh/navigation had already been fixed separately.
What changed: initialize Control UI connect auth from the explicit shared token/password before the secure-context device-auth branch, and add regression tests for insecure token/password connects.
What did NOT change (scope boundary): cached device-token fallback is still limited to the existing trusted retry path, and this PR does not change the #40892 sessionStorage same-tab behavior or add any cross-tab token sharing.

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Closes #44485
Closes #44967
Related #39611
Related #40892
Related #45070

User-visible / Behavior Changes

Control UI now preserves explicit shared token auth on insecure http:// first-connect flows instead of dropping auth before the first WebSocket handshake.
Control UI now preserves explicit shared password auth on the same insecure first-connect path.
Cached device tokens are still not sent on the insecure first connect.

Security Impact (required)

New permissions/capabilities? (No)
Secrets/tokens handling changed? (Yes)
New/changed network calls? (No)
Command/tool execution surface changed? (No)
Data access scope changed? (No)
If any Yes, explain risk + mitigation:

This restores the explicit token/password that the operator already supplied to the existing first-connect frame on insecure Control UI sessions. It does not broaden cached device-token fallback, does not add storage, and keeps the trusted retry boundary unchanged.

Repro + Verification

Environment

OS: macOS 15.7.4 (arm64)
Runtime/container: Control UI Vitest projects + local runtime repro script
Model/provider: N/A
Integration/channel (if any): Control UI
Relevant config (redacted): gateway.auth.mode: "token", gateway.controlUi.allowInsecureAuth: true, gateway.controlUi.dangerouslyDisableDeviceAuth: true

Steps

Open the Control UI over plain HTTP with an explicit shared token or password configured.
Let the browser receive the WebSocket connect.challenge event.
Inspect the first connect request payload.

Expected

The first connect frame includes the explicit shared token or password.
No cached device token is sent on that insecure first connect.

Actual

Before this fix, insecure contexts built the first connect frame from an empty auth selection state, so params.auth was omitted entirely.

Evidence

Failing test/log before + passing after
Trace/log snippets
Screenshot/recording
Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

Verified scenarios:
- insecure http:// connect with explicit shared token now sends auth.token
- insecure http:// connect with explicit shared password now sends auth.password
- existing trusted one-shot device-token retry tests still pass unchanged
- existing same-tab navigation/refresh browser tests from #40892 still pass
Edge cases checked:
- insecure first-connect still omits cached deviceToken
- secure-context explicit shared auth still signs with the shared token rather than the cached device token
What you did not verify:
- a manual live repro against a remote VPS/reverse-proxy deployment

Review Conversations

I replied to or resolved every bot review conversation I addressed in this PR.
I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

Backward compatible? (Yes)
Config/env changes? (No)
Migration needed? (No)
If yes, exact upgrade steps:

Failure Recovery (if this breaks)

How to disable/revert this change quickly: revert commit 60abd798cffa99a9f03ac9936c47e8dc3f87deca
Files/config to restore: ui/src/ui/gateway.ts and ui/src/ui/gateway.node.test.ts
Known bad symptoms reviewers should watch for: insecure HTTP Control UI connects still fail with device identity required, or cached device tokens start appearing on the first insecure connect

Risks and Mitigations

Risk: restoring explicit shared auth on insecure contexts could accidentally reintroduce cached device-token fallback on the same path.
- Mitigation: the new tests assert token/password presence while also asserting deviceToken stays absent.

Changed files

CHANGELOG.md (modified, +1/-1)
ui/src/ui/gateway.node.test.ts (modified, +72/-0)
ui/src/ui/gateway.ts (modified, +7/-2)

Code Example

Gateway log on browser connect attempt:

19:26:52 warn gateway/ws Loopback connection with non-local Host header. 
  Treating it as remote. If you're behind a reverse proxy, set 
  gateway.trustedProxies and forward X-Forwarded-For/X-Real-IP.

19:26:52 warn gateway/ws {
  "cause": "device-required",
  "handshake": "failed",
  "host": "187.77.222.15:50192",
  "origin": "http://187.77.222.15:50192",
  "client": "openclaw-control-ui",
  "version": "2026.3.11"
} closed before connect code=1008 reason=device identity required

Also tried SSH tunnel (localhost:8080 -> localhost:50192):
- Same result: cause=device-required, code=1008
- `openclaw devices list` shows no pending devices — 
  connection rejected before pairing handshake can register

Downgrading to 2026.3.8 with same config restores normal behavior.

RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Summary

Steps to reproduce

Run OpenClaw 2026.3.8 on a VPS behind a reverse proxy over HTTP (no HTTPS)
Set gateway.controlUi.dangerouslyDisableDeviceAuth: true in openclaw.json
Confirm Control UI works in browser — connects successfully
Upgrade to 2026.3.11: npm i -g [email protected] --prefix /usr/local
Restart gateway
Open Control UI in browser — fails with "device identity required"

Gateway log shows: cause: "device-required" handshake: "failed" code=1008 reason=device identity required

No pending device appears in openclaw devices list — connection is rejected before pairing handshake.

Expected behavior

With dangerouslyDisableDeviceAuth: true, the gateway should skip device identity checks and allow browser connections over HTTP, as it did in 2026.3.8.

Actual behavior

Device identity is enforced regardless of the flag. Browser connections are rejected at the WebSocket level before device pairing can register.

OpenClaw version

2026.3.11 (29dc654)

Operating system

Ubuntu 24.04 (Hostinger VPS Docker container)

Install method

docker (Hostinger managed OpenClaw VPS image)

Model

anthropic/claude-sonnet-4-5

Provider / routing chain

openclaw -> anthropic

Config file / key location

No response

Additional provider/model setup details

Gateway config:

mode: local
bind: loopback
trustedProxies: ["127.0.0.1/32"]
controlUi.dangerouslyDisableDeviceAuth: true
controlUi.allowInsecureAuth: false (also tried true, same result)
controlUi.allowedOrigins: ["http://187.77.222.15:50192", "http://localhost:8080"]

Hostinger setup: Docker container behind Hostinger's internal reverse proxy (nginx). Proxy forwards to localhost:18789, exposed externally on port 50192. No HTTPS configured — all connections are plain HTTP.

Logs, screenshots, and evidence

Gateway log on browser connect attempt:

19:26:52 warn gateway/ws Loopback connection with non-local Host header. 
  Treating it as remote. If you're behind a reverse proxy, set 
  gateway.trustedProxies and forward X-Forwarded-For/X-Real-IP.

19:26:52 warn gateway/ws {
  "cause": "device-required",
  "handshake": "failed",
  "host": "187.77.222.15:50192",
  "origin": "http://187.77.222.15:50192",
  "client": "openclaw-control-ui",
  "version": "2026.3.11"
} closed before connect code=1008 reason=device identity required

Also tried SSH tunnel (localhost:8080 -> localhost:50192):
- Same result: cause=device-required, code=1008
- `openclaw devices list` shows no pending devices — 
  connection rejected before pairing handshake can register

Downgrading to 2026.3.8 with same config restores normal behavior.

Impact and severity

Additional information

Last known good version: 2026.3.8 First known bad version: 2026.3.11

Note: npm version pinning appears broken — npm i -g [email protected] installs but package.json shows 2026.3.11. The skeleton copy is the only reliable rollback path on Hostinger.

Also note: trustedProxies is set to ["127.0.0.1/32"] and the gateway log still warns "Loopback connection with non-local Host header. Treating it as remote." — suggesting trustedProxies may not be working correctly with Hostinger's proxy setup, which could be contributing to the device-required rejection.

Environment details:

Host OS: Ubuntu 24.04.4 LTS (6.8.0-101-generic x86_64)
Docker container: Hostinger managed OpenClaw VPS image
Node: v22.22.0
Browser: Safari 26.1 (macOS Sequoia)
Network: HTTP only, no HTTPS, behind Hostinger internal nginx reverse proxy
External IP: VPS public IP, port 50192
Internal: localhost:18789

extent analysis

Fix Plan

To resolve the issue, we need to modify the gateway configuration to correctly handle the trustedProxies setting and ensure that the dangerouslyDisableDeviceAuth flag is respected.

Update trustedProxies setting: Modify the trustedProxies setting to include the IP address of the reverse proxy. In this case, add the IP address of the Hostinger internal reverse proxy to the trustedProxies list.
Set X-Forwarded-For header: Ensure that the X-Forwarded-For header is being forwarded by the reverse proxy. This header is required for the trustedProxies setting to work correctly.
Verify dangerouslyDisableDeviceAuth flag: Confirm that the dangerouslyDisableDeviceAuth flag is set to true in the openclaw.json configuration file.

Example configuration updates:

{
  "gateway": {
    "trustedProxies": ["127.0.0.1/32", "10.0.0.1/32"], // Add IP address of reverse proxy
    "controlUi": {
      "dangerouslyDisableDeviceAuth": true
    }
  }
}

In the reverse proxy configuration (e.g., nginx), ensure that the X-Forwarded-For header is being forwarded:

http {
  ...
  upstream openclaw {
    server localhost:18789;
  }
  server {
    ...
    location / {
      proxy_pass http://openclaw;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
    }
  }
}

Verification

After applying the configuration updates, restart the openclaw service and attempt to connect to the Control UI using a browser. The connection should be successful, and the device identity required error should be resolved.

Extra Tips

Ensure that the X-Forwarded-For header is being forwarded correctly by the reverse proxy.
Verify that the trustedProxies setting is correctly configured to include the IP address of the reverse proxy.
If issues persist, check the openclaw logs for any errors or warnings related to the trustedProxies setting or the dangerouslyDisableDeviceAuth flag.

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

FAQ

Expected behavior

With dangerouslyDisableDeviceAuth: true, the gateway should skip device identity checks and allow browser connections over HTTP, as it did in 2026.3.8.

#api #ssr #installation #tensor shape #autograd error #memory management #API rate limit #retriever error #indexing error #inference speed

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

openclaw - ✅(Solved) Fix [Bug]: `dangerouslyDisableDeviceAuth: true` ignored in 2026.3.11 — Control UI rejects HTTP connections with "device identity required" [3 pull requests, 4 comments, 3 participants]

Recommended Tools

GitHub issue graph ai analysis

Error Message

Root Cause

Fix Action

Fix / Workaround

PR fix notes

PR #44486: fix(gateway): honor dangerouslyDisableDeviceAuth regardless of sharedAuthOk

Description (problem / solution / changelog)

Problem

Root Cause

Solution

Testing

Impact

Changed files

PR #45070: fix(gateway): always resolve device token for fallback auth during SPA navigation

Description (problem / solution / changelog)

Summary

What changed

Production code (2 files)

Test code (2 files)

Root cause analysis

How to test

Related issues

Changed files

PR #45088: fix(ui): keep shared auth on insecure control-ui connects

Description (problem / solution / changelog)

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

User-visible / Behavior Changes

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Failure Recovery (if this breaks)

Risks and Mitigations

Changed files

Code Example

Bug type

Summary

Steps to reproduce

Expected behavior

Actual behavior

OpenClaw version

Operating system

Install method

Model

Provider / routing chain

Config file / key location

Additional provider/model setup details

Logs, screenshots, and evidence

Impact and severity

Additional information

extent analysis

Fix Plan

Verification

Extra Tips

FAQ

Expected behavior

Still need to ship something?

RELATED_DISCOVERY

TRENDING