Summary

gateway.controlUi.allowInsecureAuth: true does not bypass device pairing requirement when accessing the Control UI via a reverse proxy (StartOS/Docker deployment).

Steps to reproduce

1. Deploy Clawdbot in Docker container on StartOS
2. Configure clawdbot.json with:

{
  "gateway": {
    "mode": "local",
    "bind": "lan",
    "port": 18789,
    "controlUi": {
      "enabled": true,
      "allowInsecureAuth": true
    },
    "auth": {
      "mode": "token",
      "token": "your-token-here"
    }
  },
  "agents": {
    "defaults": {
      "workspace": "/root/clawd"
    }
  }
}

3. Access the Control UI via StartOS's HTTPS reverse proxy (e.g., https://xxxxx.local/?token=your-token-here)
4. Also tried "mode": "password" with password in URL and localStorage

Expected behavior

According to the [v2026.1.21 release notes](https://github.com/clawdbot/clawdbot/releases/tag/v2026.1.21):

"Control UI now rejects insecure HTTP without device identity by default. Use HTTPS (Tailscale Serve) or set gateway.controlUi.allowInsecureAuth: true to allow token-only auth."

And the [Security docs](https://docs.clawd.bot/gateway/security):

"If you enable gateway.controlUi.allowInsecureAuth, the UI falls back to token-only auth on plain HTTP and skips device pairing."

With allowInsecureAuth: true, the Control UI should accept token/password authentication without requiring device pairing.

Actual behavior

The Control UI consistently returns:

disconnected (1008): pairing required

The gateway logs show:

[ws] unauthorized conn=xxx remote=172.18.0.1 client=clawdbot-control-ui webchat vdev reason=token_missing

Even after:

• Setting the token correctly in localStorage (clawdbot-auth-token and clawdbot.control.settings.v1)
• Passing token via URL parameter (?token=xxx)
• Switching to password mode and passing password via URL
• Clearing all browser cache/localStorage and using incognito mode

The token IS being sent (verified in logs when switching from "pairing required" to "token missing" errors), but the pairing requirement is never bypassed despite allowInsecureAuth: true.

Environment

• Clawdbot version: latest (installed via npm install -g clawdbot@latest in Docker)
• OS: StartOS (Ubuntu-based) running Docker container
• Install method: Docker container deployed as StartOS service
• Browser: Chrome 144 on Windows 11

Logs or screenshots

Config being loaded (from container logs):

=== Clawdbot Starting ===
============================================
{
  "gateway": {
    "mode": "local",
    "bind": "lan",
    "port": 18789,
    "controlUi": {
      "enabled": true,
      "allowInsecureAuth": true
    },
    "auth": {
      "mode": "token",
      "token": "[REDACTED]"
    }
  },
  "agents": {
    "defaults": {
      "workspace": "/root/clawd"
    }
  }
}
============================================

Gateway starts successfully:

2026-01-25T00:09:55.532Z [canvas] host mounted at http://0.0.0.0:18789/__clawdbot__/canvas/
2026-01-25T00:09:55.627Z [heartbeat] started
2026-01-25T00:09:55.631Z [gateway] agent model: anthropic/claude-opus-4-5
2026-01-25T00:09:55.632Z [gateway] listening on ws://0.0.0.0:18789 (PID 14)

Connection attempts fail with pairing required:

[ws] ← open remoteAddr=172.18.0.1 conn=8f71ed8b…733a
[ws] unauthorized conn=8f71ed8b-xxx remote=172.18.0.1 client=clawdbot-control-ui webchat vdev reason=token_missing
[ws] closed before connect ... code=4008 reason=connect failed

[ws] → close code=4008 reason=connect failed durationMs=60 cause=pairing-required handshake-failed

Browser console:

disconnected (1008): pairing required

Additional context

• StartOS acts as an HTTPS reverse proxy to the container
• The connection comes from 172.18.0.1 (Docker network), not localhost
• The .local domain resolves via mDNS to the StartOS server
• SSH tunnel to access via localhost is not easily available in StartOS environment
• This affects all Docker deployments behind reverse proxies where localhost access isn't possible