gateway.controlUi.allowInsecureAuth no longer exists. OpenClaw removed it in 2026.8.1, and a config that still contains it fails validation with Unrecognized key: "allowInsecureAuth", which can stop the gateway from starting. Run openclaw doctor --fix to delete it. You do not need a replacement: since 2026.8.1 the Control UI pairs over plain HTTP. For remote access, use Tailscale Serve or an SSH tunnel.
This applies to OpenClaw 2026.8.1 and every release since, up to 2026.9.8, the current release as of October 2026. Most guides that rank for this setting still describe it as a switch you can turn on. That stopped being true two months ago.
What did allowInsecureAuth do?
It was an escape hatch for the browser dashboard. In 2026.1.21 the Control UI started rejecting plain HTTP connections that had no device identity. The changelog suggested two ways out: serve over HTTPS with Tailscale Serve, or set gateway.controlUi.allowInsecureAuth: true to allow token-only auth.
Plenty of people took the one-line option. They had OpenClaw on a VPS or a home server, opened http://<server-ip>:18789, and got one of these:
disconnected (1008): control ui requires HTTPS or localhost (secure context)(issue #16423)device identity required(issue #29801)
Browsers only allow the cryptography the old Control UI used for device identity on HTTPS or localhost. Over a bare IP there was no identity, so the gateway refused the connection, and allowInsecureAuth told it to accept the shared token alone.
The catch is that over plain HTTP that token crosses the network in cleartext. Anyone on the path can read it or change the page, and the token controls an agent that holds your tools and API keys. In 2026.2.21 OpenClaw required a secure context and paired-device checks even with the flag set, so it already did much less than most guides claimed.
Why does my config fail with "Unrecognized key"?
Because the key was removed from the config schema. The config-surface cleanup in PR #111527 retired allowInsecureAuth from both the schema and the runtime, and 2026.8.1 (the release also called OpenClaw 2.0) is the first stable version that includes it. A later fix, PR #120295, describes the setting as "retired, rejected by current config validation, and removed by openclaw doctor --fix". OpenClaw's own test suite lists gateway.controlUi.allowInsecureAuth among its dead config keys.
What you see depends on how the key got there:
| Symptom | Cause | Fix |
|---|---|---|
Gateway will not start; log shows Invalid config at ... with Unrecognized key: "allowInsecureAuth" | The key survived an upgrade to 2026.8.1 or later | openclaw doctor --fix |
Gateway keeps running, log shows config reload skipped (invalid config): | You added the key by hand to a running gateway | Remove it; the running config is unchanged |
openclaw config set gateway.controlUi.allowInsecureAuth true is rejected | The schema no longer knows the key | Do not set it; pair the browser instead |
| systemd unit stays down after the upgrade | An invalid config exits with code 78 and the unit will not restart on it | Fix the config, then restart |
The config validation page explains the behavior: startup refuses a config that still needs legacy-key repair and prints a doctor hint, and hot reload ignores invalid edits. The gateway page documents the exit code 78 and the RestartPreventExitStatus=78 setting.
How do I fix it?
Check the config, let doctor remove the retired key, and check again:
openclaw config validate
openclaw doctor --fix
openclaw config validate
openclaw gateway restartIf you prefer to edit by hand, openclaw config file prints the path of the active config. Delete the allowInsecureAuth line from the gateway.controlUi block and keep the rest of the file intact. Delete dangerouslyDisableDeviceAuth while you are in there. OpenClaw's network exposure docs call it a "retired break-glass input, now fully inert", so it does nothing at all, and doctor removes it too.
If the upgrade broke more than this one key, our guide to fixing OpenClaw after an update walks the full recovery.
Does the Control UI work over plain HTTP now?
Yes. Since 2026.8.1 (PR #124724) the Control UI generates and signs its device identity with a pure JavaScript Ed25519 implementation. The connect and pair page says it directly: opening the dashboard at http://<lan-ip> or http://<tailscale-ip> "works", and "pairing does not depend on WebCrypto or a secure context". The signing key never leaves the browser.
So the reason anyone set allowInsecureAuth is gone. A browser on plain HTTP now pairs like any other device. The first time it connects you see disconnected (1008): pairing required, and you approve it on the gateway host:
openclaw devices list
openclaw devices approve <requestId>Keep the browser tab open while you approve, and it connects on its own. If the approval loops or the request id keeps changing, read our guide to the OpenClaw pairing required error.
There is also no longer any config switch that turns device identity off. The docs state "there is no persistent config switch that disables device identity". The one exception is an operator session that authenticates through gateway.auth.mode: "trusted-proxy".
Is plain HTTP safe enough, then?
Pairing works over HTTP, but the connection is still unencrypted. The shared gateway token, the page and all its traffic can be read or altered by anyone on the network path. The OpenClaw docs call HTTP "a LAN-only convenience". Their recommended setup is HTTPS through Tailscale Serve, or the UI at http://127.0.0.1:18789/ on the gateway host itself.
Do not use plain HTTP on a VPS over the open internet. Use one of these instead.
Tailscale Serve
The gateway stays on loopback and Tailscale puts HTTPS with a real certificate in front of it, reachable only from your tailnet. For a one-off run:
openclaw gateway --tailscale serveFor an installed service, set it in config and restart:
openclaw config set gateway.tailscale.mode serve
openclaw gateway restartThen open https://<magicdns>/. When gateway.auth.allowTailscale is on, OpenClaw verifies the Tailscale identity and can skip the pairing round trip for an operator browser. The Tailscale page covers Funnel and direct tailnet binds.
SSH tunnel
If you can already SSH into the server, a tunnel needs nothing else:
ssh -N -L 18789:127.0.0.1:18789 user@gateway-hostThen open http://127.0.0.1:18789/ on your own machine. The browser is now on localhost and the traffic is encrypted by SSH. Gateway auth still applies. The gateway docs note that "SSH tunnels do not bypass gateway auth", so you still need the token.
On the host
If you are on the gateway host itself, openclaw dashboard opens a short-lived, single-use owner link, which is the fastest way in. On a headless host, openclaw dashboard --json prints the link as browserUrl instead.
What about "origin not allowed"?
That is a different check, and it often shows up right after people remove allowInsecureAuth and put a reverse proxy in front. The Control UI troubleshooting page says private same-origin loads (LAN and Tailscale addresses, .local and .ts.net hosts) need no allowlist entry. A public domain or cross-origin setup needs the origin in gateway.controlUi.allowedOrigins, or gateway.publicOrigin set. Avoid ["*"]. Behind nginx, Caddy or Traefik, also set gateway.trustedProxies.
While you are hardening, run openclaw security audit. It flags the insecure flags that are still live, such as dangerouslyAllowHostHeaderOriginFallback. Our OpenClaw security checklist covers binding, auth and secrets more broadly.
What this looks like when someone else runs the gateway
On Qoren, each OpenClaw agent's gateway keeps OpenClaw's default loopback bind, and Qoren never writes allowInsecureAuth or any other Control UI flag into its config. You reach the agent through the Qoren console, the CLI or the SDK, so no dashboard port faces the internet. A daily checkup runs openclaw doctor on every agent and lets doctor --fix repair what it finds. Doctor is also the tool that removes retired keys like this one, so a leftover from an upgrade does not wait for you to edit JSON. You can run the same checkup yourself with qoren agent doctor <id>, or see how to repair an agent from the console.