OpenClaw Dashboard: Run Your Agent From a Browser Without Losing Control

A lot of agent tooling gets awkward the moment you leave the terminal. You either get a glossy dashboard that hides the real system, or you get a raw API surface that only makes sense if you already know the internals. OpenClaw takes a more useful path. Its dashboard is simply the browser Control UI served by the Gateway, on the same port as the Gateway WebSocket, with the same auth model and the same operational edges.

That matters because the dashboard is not a toy status page. According to the docs, it can chat with the model, stream tool calls and live tool output cards, manage channel logins, inspect sessions, edit config, manage cron jobs, review exec approvals, inspect logs, and run updates. It is an admin surface, not a marketing demo.

If you run agents daily, that is exactly what you want. You do not want a separate product layer that drifts away from the real runtime. You want a browser entry point into the same Gateway that already owns sessions, tools, auth, and config.

OpenClaw has had browser surfaces for a while, but the current docs make the model much clearer. The dashboard lives at / by default, or under a custom prefix if you set gateway.controlUi.basePath. On a local machine, the quick-open URL is http://127.0.0.1:18789/.

What the dashboard actually is

The docs call it the Control UI, a small Vite and Lit single-page app served directly by the Gateway. It speaks to the Gateway over WebSocket on the same port. That design keeps the browser UI close to the actual runtime instead of adding another service to babysit.

OpenClaw also has a WebChat concept, but the docs are explicit about the split. WebChat uses the Gateway WebSocket for chat UI behavior, while the Control UI is the broader browser-based admin layer. The Control UI includes chat, but it also reaches into sessions, nodes, cron, skills, config, logs, and channel setup.

In practice, I think of it this way:

• WebChat is the chat path and transcript surface.
• Control UI is the operator cockpit.
• Dashboard is the quick name for opening that Control UI in a browser.

That separation is healthy. If all you need is messaging, use the chat surface. If you need to operate the actual agent stack, use the dashboard.

How you open it fast

The fastest path in the docs is simple: run openclaw dashboard. After onboarding, the CLI auto-opens the dashboard and prints a clean link. You can also open the local URL directly.

openclaw dashboard
# or open http://127.0.0.1:18789/

If the page does not load, the docs say to start the Gateway first with openclaw gateway. That sounds obvious, but it is the right mental model: the dashboard is served by the Gateway, not by some detached frontend server you forgot to boot.

The docs also note that the Gateway serves static files from dist/control-ui. If you are building the UI from source, pnpm ui:build builds those assets and pnpm ui:dev starts a development server. That is helpful if you are customizing or debugging the UI itself, but most operators just need the standard browser entry point.

Auth is part of the design, not an afterthought

This is the part I am happiest to see documented plainly. The dashboard is an admin surface. The docs explicitly warn not to expose it publicly. Authentication is enforced at the WebSocket handshake, using connect.params.auth.token or connect.params.auth.password, with additional identity-aware modes in some setups.

For a normal local setup, the pattern is straightforward:

• open http://127.0.0.1:18789/
• use the configured gateway token from gateway.auth.token or OPENCLAW_GATEWAY_TOKEN, or use the configured password
• paste it into the Control UI settings if prompted

The docs say the UI keeps dashboard URL tokens in sessionStorage for the current browser tab session and selected gateway URL, and strips them from the URL after load. Passwords are not persisted across reloads. That is a small detail, but it is exactly the kind of detail that tells you the team is thinking about how admin surfaces leak secrets in real life.

There is also a useful edge case called out in the docs. If gateway.auth.token is managed as a SecretRef and is unresolved in your current shell, openclaw dashboard still opens or prints a non-tokenized link and gives auth guidance instead of spraying secrets into shell history or browser launch arguments.

Remote access is where people get sloppy, so do it the documented way

If you want remote browser access, OpenClaw gives you a few patterns, and the docs clearly favor one of them: Tailscale Serve.

The recommended setup is to keep the Gateway bound to loopback and let Tailscale Serve proxy it over HTTPS. The relevant config in the docs is:

{
  gateway: {
    bind: "loopback",
    tailscale: { mode: "serve" },
  },
}

Then you start the Gateway and open the MagicDNS HTTPS URL. In that Serve path, the docs say Control UI and WebSocket auth can use Tailscale identity headers when gateway.auth.allowTailscale is true. If you do not want that tokenless behavior, set gateway.auth.allowTailscale to false and require explicit credentials.

That is a good tradeoff. On a trusted gateway host inside your tailnet, Tailscale Serve is clean and ergonomic. If the host itself is not fully trusted, require token or password auth and tighten the path.

The docs also describe a tailnet bind plus token pattern, where you bind the Gateway to tailnet and require gateway.auth.mode: "token". That works, but it is less elegant than loopback plus Serve. And for public internet exposure, the docs move to Tailscale Funnel plus password mode, which is a stronger reminder that public access changes the risk picture fast.

New browser or device? Pairing is expected

One of the most practical sections in the Control UI docs is device pairing. When you connect from a new browser or device, the Gateway can require one-time pairing approval, even on the same tailnet when gateway.auth.allowTailscale is enabled. The visible symptom is a disconnect message like disconnected (1008): pairing required.

The documented fix is:

openclaw devices list
openclaw devices approve <requestId>

The docs also note that local 127.0.0.1 connections are auto-approved, while remote connections need explicit approval. Each browser profile generates its own device ID, so changing browsers or clearing browser data can trigger re-pairing. That is annoying in the exact right way. It prevents remote browser access from quietly becoming anonymous admin access.

What you can actually do from the Control UI

This is where the dashboard becomes more than a convenience. The docs list a real operational surface area:

• chat over the Gateway WebSocket, including history, send, abort, and inject flows
• streamed tool calls and live tool output cards
• channel status, QR login flows, and per-channel config
• session listing and per-session thinking, fast, verbose, and reasoning overrides
• cron job listing, editing, enabling, disabling, and run history
• skills status, install, enable, disable, and API key updates
• node listing
• exec approvals editing for gateway or node execution policies
• config view, edit, schema-driven forms, and validated apply plus restart
• live logs, health and model snapshots, and update runs

That list tells you something important about OpenClaw itself. The browser layer is not pretending to be safer by hiding the dangerous parts. Instead, it exposes the real control plane and adds guardrails like auth, device pairing, config validation, and base-hash protection for config writes.

If you have already read my post on session tools, the browser view fits nicely with that model. Sessions are still real units of work. The dashboard just makes them easier to inspect and steer without dropping to the CLI for every adjustment.

Chat behavior in the browser is intentionally operational

The WebChat and Control UI docs both emphasize that browser chat is not magical transport. It uses the Gateway WebSocket and the same chat methods: chat.history, chat.send, and chat.inject.

Some details here are worth remembering:

• chat.send is non-blocking and acknowledges immediately with a started status
• responses stream back through chat events
• chat.history is size-bounded, and the Gateway may truncate oversized fields for UI stability
• chat.inject appends an assistant note to the transcript without running the agent
• aborted runs can keep partial assistant output visible, and buffered partial output can be persisted with abort metadata

I like this because it keeps the browser honest. It is not a fake conversation layer. It is a structured client for the real Gateway behavior.

Two security mistakes to avoid

First, do not treat the dashboard as something you should casually put on the public internet. The docs say not to expose it publicly, and they are right. This UI can reach config, chat, exec approvals, and operational controls.

Second, do not normalize insecure HTTP remote usage. The docs explain that plain HTTP on a LAN or tailnet can put the browser into a non-secure context where WebCrypto is blocked. OpenClaw provides compatibility toggles like gateway.controlUi.allowInsecureAuth and a break-glass dangerouslyDisableDeviceAuth, but the docs frame them appropriately: compatibility or emergency options, not default posture.

If you need remote browser access, use the secure path first. That is usually localhost, Tailscale Serve, or an SSH tunnel.

Bottom line

The OpenClaw dashboard is useful because it is boring in the right places. It is just the Gateway's Control UI in a browser, on the same port, with the same auth, talking to the same runtime. That means less surface area drift, fewer fake abstractions, and a cleaner path from terminal-first operations to browser-based control.

If you want one rule to remember, make it this: use the dashboard as an admin surface, not as a public app. Open it locally when you can. Use Tailscale Serve or an SSH tunnel when you need remote access. Expect pairing on new devices. And treat every shortcut that weakens browser auth as temporary.

Want the complete guide? Get ClawKit — $9.99