bug(gateway): dangerouslyDisableDeviceAuth nullifies device identity instead of bypassing pairing check

[jyaunches]

Context

This bug was discovered by a NemoClaw user (NVIDIA/NemoClaw#563) and surfaced during post-merge cleanup of NVIDIA/NemoClaw#1217, which hardened gateway auth defaults in the NemoClaw Dockerfile. We believe the root cause is in OpenShell's gateway resolveControlUiAuthPolicy implementation rather than in NemoClaw.

Description

Setting gateway.controlUi.dangerouslyDisableDeviceAuth: true in openclaw.json is intended to bypass device-pairing authentication (for development, headless, or reverse-proxy setups). Instead, it nullifies the device identity, causing the gateway to reject the connection with code=1008 reason=device identity required.

This creates a catch-22:

• dangerouslyDisableDeviceAuth: true → device set to null → hasDeviceIdentity is false → rejected with "device identity required"
• dangerouslyDisableDeviceAuth: false → device identity preserved but pairing enforced → pairing required (and openclaw devices approve may fail)

Root Cause (as identified by reporter)

In gateway-cli-BjsM6fWb.js, the resolveControlUiAuthPolicy function:

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. Downstream, evaluateMissingDeviceIdentity() sees no device identity and rejects. The flag sets allowBypass: true but then removes the device identity that would allow the bypass to work.

Expected Fix

The device field should preserve params.deviceRaw regardless of the dangerouslyDisableDeviceAuth flag:

device: params.deviceRaw

This would preserve the device identity while still allowing allowBypass to skip the pairing check — which appears to be the intended behavior of the flag.

NemoClaw Mitigation

NemoClaw PR #1217 mitigated this by defaulting dangerouslyDisableDeviceAuth to false (secure by default) and making it a build-time-only setting. 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.

Reproduction Steps

1. Set gateway.controlUi.dangerouslyDisableDeviceAuth: true in openclaw.json
2. Set gateway.controlUi.allowInsecureAuth: true
3. Configure a reverse proxy (e.g., Caddy) to proxy to 127.0.0.1:18789
4. Open the proxied URL in a browser
5. Expected: Browser connects, device auth is bypassed, token login screen appears
6. Actual: Gateway rejects with code=1008 reason=device identity required

Environment (from original reporter)

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

Question

Can you confirm this is an OpenShell gateway fix? We want to make sure we're filing in the right place. Feel free to reach out to me (@jyaunches) with any questions.

[drew]

OpenShell's gateway does not implement or control resolveControlUiAuthPolicy. This report belongs in the NemoClaw repository.

[jyaunches]

Thanks @drew — you're right, this is in OpenClaw's gateway code, not OpenShell. Apologies for the misdirected filing. We'll route this upstream to the OpenClaw repo.