dangerouslyDisableDeviceAuth nullifies device identity, causing 'device identity required' rejection

[vikasgaddu1]

Bug Summary

gateway.controlUi.dangerouslyDisableDeviceAuth: true makes the Control UI completely inaccessible through a reverse proxy (Caddy, Traefik, etc.) by nullifying the device identity instead of bypassing the device check.

Environment

• NemoClaw v0.1.0
• OpenClaw 2026.3.11 (29dc654)
• OpenShell v0.0.12
• Ubuntu 24.04 on Hostinger VPS
• Caddy v2.11.2 as reverse proxy

Steps to Reproduce

1. Install NemoClaw, set up sandbox
2. Configure Caddy to reverse proxy yourdomain.com → 127.0.0.1:18789
3. Set gateway.controlUi.allowedOrigins to include your domain
4. Set gateway.controlUi.dangerouslyDisableDeviceAuth: true
5. Set gateway.controlUi.allowInsecureAuth: true
6. Open https://yourdomain.com in a browser

Expected: Browser connects, device auth is bypassed, token login screen appears.

Actual: Gateway rejects with code=1008 reason=device identity required. The token login screen never appears.

Root Cause

In gateway-cli-BjsM6fWb.js, the resolveControlUiAuthPolicy function (around line 22349):

function resolveControlUiAuthPolicy(params) {
    const allowInsecureAuthConfigured = params.isControlUi && params.controlUiConfig?.allowInsecureAuth === true;
    const dangerouslyDisableDeviceAuth = params.isControlUi && params.controlUiConfig?.dangerouslyDisableDeviceAuth === true;
    return {
        allowInsecureAuthConfigured,
        dangerouslyDisableDeviceAuth,
        allowBypass: dangerouslyDisableDeviceAuth,
        device: dangerouslyDisableDeviceAuth ? null : params.deviceRaw  // ← BUG
    };
}

When dangerouslyDisableDeviceAuth is true, device is set to null. This makes hasDeviceIdentity evaluate to false downstream in evaluateMissingDeviceIdentity(), which then rejects with "device identity required".

The flag creates a catch-22:

• dangerouslyDisableDeviceAuth: true → device set to null → "device identity required"
• dangerouslyDisableDeviceAuth: false → device identity preserved but pairing enforced → "pairing required" (and openclaw devices approve fails with GatewayClientRequestError: unknown requestId)

Fix

Change line ~22357 from:

device: dangerouslyDisableDeviceAuth ? null : params.deviceRaw

To:

device: params.deviceRaw

This preserves the device identity while still allowing allowBypass to skip the pairing check. After this patch, the browser successfully connects and the token login screen appears.

Additional Issues Found

1. openclaw devices approve <id> crashes with GatewayClientRequestError: unknown requestId — CLI device management is broken
2. openclaw gateway stop is the only way to stop the gateway — Ctrl+C doesn't work inside the sandbox
3. Token must be passed via URL hash (https://domain/#token=xxx), not query parameter — this is undocumented for remote access

Workaround

Patch the file manually inside the sandbox:

python3 -c "
path = '/usr/local/lib/node_modules/openclaw/dist/gateway-cli-BjsM6fWb.js'
with open(path, 'r') as f:
    code = f.read()
code = code.replace(
    'device: dangerouslyDisableDeviceAuth ? null : params.deviceRaw',
    'device: params.deviceRaw'
)
with open(path, 'w') as f:
    f.write(code)
print('Patched')
"

Then set config:

openclaw config set gateway.controlUi.dangerouslyDisableDeviceAuth true
openclaw config set gateway.controlUi.allowInsecureAuth true
openclaw config set gateway.controlUi.allowedOrigins '["https://yourdomain.com"]'

Restart the gateway and access via https://yourdomain.com/#token=YOUR_GATEWAY_TOKEN.

[wscurran]

Thanks for reporting this issue, it seems like the gateway control UI is being made inaccessible due to a device identity issue, which could be a bug in the platform.

[jyaunches]

We investigated this as part of post-merge cleanup for PR #1217. Here's what we found:

Root cause is upstream in OpenClaw

The buggy code is in OpenClaw's src/gateway/server/ws-connection/connect-policy.ts — specifically the resolveControlUiAuthPolicy() function, which sets device: null when dangerouslyDisableDeviceAuth is true. NemoClaw only writes the config value into openclaw.json; the gateway code that mishandles it belongs to the OpenClaw project.

This is a known issue upstream with multiple open reports on the OpenClaw repo:

• openclaw/openclaw#40812 — regression since v2026.3.7
• openclaw/openclaw#43164 — detailed analysis of the evaluateMissingDeviceIdentity code path
• openclaw/openclaw#43909 — confirmed broken in v2026.3.11

NemoClaw mitigation via #1217

PR #1217 mitigated this on the NemoClaw side by:

• Defaulting dangerouslyDisableDeviceAuth to false (secure by default)
• Making it a build-time-only setting (NEMOCLAW_DISABLE_DEVICE_AUTH build arg)

Most users will no longer encounter this. However, anyone who opts in with --build-arg NEMOCLAW_DISABLE_DEVICE_AUTH=1 (for headless/development use) will still hit this bug until OpenClaw fixes the upstream issue.

Recommendation

Closing this as upstream — the fix needs to happen in OpenClaw's gateway code, not in NemoClaw. The existing OpenClaw issues linked above are tracking it.