How to Use OpenClaw Control UI

OpenClaw Control UI is the browser interface behind the dashboard. The docs describe it as a small Vite + Lit single-page app served by the gateway, usually at http://127.0.0.1:18789/. It speaks directly to the gateway WebSocket, so it is not just a pretty status page. It is a live control surface for chat, Talk, channels, sessions, dreams, cron jobs, skills, nodes, config, logs, updates, and exec approvals.

Start with connection and pairing

On the gateway host, open the local URL or run openclaw dashboard. From another browser or device, expect a pairing flow unless the docs' trusted cases apply. A new browser profile can receive disconnected (1008): pairing required. Approve it with openclaw devices list followed by openclaw devices approve <requestId>. If the browser retries with different auth details, the old request can be superseded, so list pending requests again before approving.

Use the main operator panels

The chat and Talk areas let you send messages through the gateway session and watch live tool output cards. The channel section shows bundled and plugin channel status, login flows, QR flows, and config controls. Sessions expose model, thinking, fast, verbose, trace, and reasoning overrides. Nodes show connected device capabilities. Cron and skills panels let you list, add, edit, run, enable, disable, or install the things that make OpenClaw feel autonomous.

Edit config carefully

Control UI can view and edit the active OpenClaw config. The docs mention schema-backed forms, raw JSON mode, validation, restart application, base-hash guards, and SecretRef preflight checks. Those guards matter because config edits can restart a gateway or change who is allowed to talk to the assistant. Prefer the form view for routine edits, use raw mode only when you know the shape, and never treat a browser config editor as a place for experiments you cannot explain later.

Keep identity local when intended

Some Control UI state is deliberately browser-local. Personal display name, avatar, assistant avatar overrides, imported themes, and selected locale can live in browser storage instead of being written to shared gateway config. That is a useful boundary in shared operator setups: the UI can feel personal without changing the gateway for everyone else. If something does not appear on another device, check whether it is a browser-local preference before debugging the gateway.

Best operating pattern

Use Control UI as your situational-awareness layer, not your only source of truth. When something fails, pair the UI symptom with the CLI or logs: device pairing, gateway status, config validation, and approval state all have CLI references. The OpenClaw Playbook turns that into a repeatable routine: observe in Control UI, verify with a small command, make one change, and record what changed. That rhythm keeps the power of the UI without letting it become a risky click console.

Where Control UI fits in the stack

Think of Control UI as an operator workspace layered on top of the gateway, not as a replacement for the gateway. The gateway owns state, sessions, pairing, channel config, and tool execution. Control UI gives you a browser way to see and change that state. That mental model helps when debugging: if a panel fails to load, ask whether the browser cannot fetch the runtime config, the WebSocket handshake failed, the device needs approval, or the gateway itself is down. Separating those layers makes problems smaller and keeps you from randomly changing config when the real issue is just a stale browser identity.

Final verification

Before calling How to Use OpenClaw Control UI 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.