How to Use the OpenClaw Dashboard

The OpenClaw dashboard is the browser entry point for operating a gateway. In current docs it is the Control UI served at / by default, usually on http://127.0.0.1:18789/. If gateway TLS is enabled, the matching browser URL becomes HTTPS and the WebSocket endpoint uses WSS. Treat the dashboard as an operator console, not a public website: it can reach chat, config, sessions, nodes, cron, skills, and exec approvals.

Open it the safe way

The fast path is simple: after onboarding, OpenClaw normally opens the dashboard and prints a clean link. Later, run openclaw dashboard. That command is better than copying old URLs because it knows about the gateway's current bind, TLS mode, headless SSH hints, and token handling. If your gateway token is stored through SecretRef, the command intentionally prints a non-tokenized URL instead of putting a sensitive token into command history or browser-launch arguments.

Understand the auth prompt

Dashboard authentication happens during the WebSocket handshake. The docs list shared token auth, shared password auth, Tailscale identity headers, and trusted-proxy identity headers as supported paths. Localhost is the easiest case: open the loopback URL and connect. Remote access needs more care. If Control UI asks for a token or password, supply the configured gateway auth value in the dashboard settings. Tokens are kept in sessionStorage for that browser tab session and selected gateway URL; passwords are not persisted across reloads.

Do not put it on the open internet

This is the rule I would write on the wall: do not expose the dashboard publicly. It is an admin surface. Use localhost when you are on the gateway host, Tailscale Serve when you need tailnet access, or an SSH tunnel such as forwarding local port 18789 to the gateway. If you need a public webhook for a channel, expose only the webhook path for that channel, not the root dashboard. Keeping the dashboard private is the difference between a helpful operator UI and an unnecessary control-plane risk.

When you see unauthorized or 1008

A 1008-style disconnect usually means auth or pairing needs attention. First check reachability with openclaw status on the gateway host or through your tunnel. Then verify the shared token, password, Tailscale identity mode, or trusted proxy mode. The docs also point to token drift repair through the devices CLI when cached device tokens are stale. If no shared secret is configured, use openclaw doctor --generate-gateway-token on the gateway host, then reconnect with the new secret.

Operator workflow

Use the dashboard for active operations: check sessions, inspect channel status, manage cron jobs, view nodes, adjust skills, and handle approvals. Keep irreversible config edits deliberate. The Control UI has validation and guards, but the safest production habit is still to know what you changed, why you changed it, and how you will roll it back. The OpenClaw Playbook builds that runbook mindset around the dashboard so it becomes a calm command center instead of another tab you poke randomly.

What to document before rollout

Before you make the dashboard part of a daily operating loop, write down three facts: where the gateway runs, how the dashboard is reached, and which auth path is expected. Add the exact recovery step for a stale browser token and the human who can approve a new device. That sounds mundane, but it prevents the worst dashboard failure mode: a teammate opens an old link, sees 1008, generates a new token, and accidentally leaves three half-working access paths behind. A dashboard is supposed to reduce ambiguity. Keeping a tiny access note beside it makes the UI much safer for future agents and operators.

Final verification

Before calling How to Use the OpenClaw Dashboard finished, perform one direct test, one failure test, and one rollback check. The direct test proves the happy path works. The failure test proves the documented guardrail is real, not just assumed. The rollback check tells the next operator how to undo the change without improvising. Save those notes beside the channel, node, or gateway config you changed. OpenClaw gets powerful when agents can act, but it stays trustworthy when every new surface has a small, repeatable verification habit attached to it.