Back

OpenClaw Dashboard Guide: Web UI, Connection and Canvas

Open the OpenClaw dashboard, authenticate the Web UI, diagnose connection failures, and distinguish session dashboards from the macOS Canvas widget panel.

OpenClaw series · Part 9 · Updated October 20, 2026.

OpenClaw dashboard: open the Web UI and connect

Open http://127.0.0.1:18789/ on the machine running the Gateway. This is the browser Control UI. A remote browser needs a tunnel or configured remote endpoint; its own 127.0.0.1 points to the browser’s machine.

Before troubleshooting buttons or chat, check the Gateway:

openclaw gateway status
openclaw gateway probe

If no Gateway is running, start it through your normal service setup. For a foreground local instance, openclaw gateway starts the process; do not start a duplicate when the service is already active.

The HTML dashboard and its WebSocket connection use the same port. Seeing the page is not enough: confirm the connection indicator and an authenticated session before expecting actions to work.

Connect and authenticate

The current UI accepts the configured Gateway token or password through its Gateway secret field on the login screen or Settings → Gateway. Authentication and device pairing are separate stages. Connecting from loopback does not automatically bypass authentication.

Use the credential belonging to this Gateway, not a mobile setup code or an unrelated device token. If pairing is required, review the intended browser/device request through the supported pairing flow. Keep secrets out of screenshots, shared links, and issue reports.

For a configuration-specific failure, follow the Control UI connection guide instead of enabling insecure authentication options.

Dashboard pages and buttons: what to use

Labels vary by version and available permissions. Begin with the task you need rather than a screenshot of an older sidebar:

Task Where to look What confirms success
Send a message Chat for the selected agent/session A connected Gateway and a completed reply
Find a previous conversation Session/sidebar controls Correct agent and session, with the intended history
Choose an agent Agent menu or Agents view Selected agent identity before a new request
Inspect skills Settings for the selected agent, or its skills view Expected source and eligibility, not just a matching name
Change configuration Settings and the appropriate scoped page Save/validation result and the effective setting
Diagnose a failed action Connection status, activity, and diagnostic views The actual failed request and its reason

A disconnected UI can retain earlier content. That makes it useful to read, but it does not prove current Gateway state. Reconnect and inspect refreshed results before treating a button action as completed. Do not repeatedly press a mutating action because its first attempt has not yet produced a visible result.

For a first functional check, send a harmless message in a new test conversation. Confirm the target agent, connection, response, and any tool activity separately. This avoids confusing cached history with a successful new request.

Remote access

SSH tunnel

From your own machine:

ssh -N -L 18789:127.0.0.1:18789 user@gateway-host

Open http://127.0.0.1:18789/ locally and authenticate to the remote Gateway. If the local port is already occupied, choose a different local port and use it consistently in the browser address.

Tailscale or reverse proxy

Use the official remote-access guidance for a persistent setup. With a reverse proxy, check HTTP routing and WebSocket upgrades, the configured base path, browser origin, and the selected authentication mode.

Do not expose an unauthenticated port 18789 as a shortcut. A browser-side connection failure can come from origin validation, authentication, pairing, or transport; disabling protections conceals those distinctions.

Control UI, Canvas, and A2UI are different surfaces

The Control UI is the web application for chatting and managing OpenClaw. A session dashboard is a visual surface associated with a conversation. The current macOS Canvas/widget panel presents hosted widget documents through a paired Mac node.

Those are related capabilities, but they do not share every API. In particular, the current macOS panel documentation explicitly distinguishes that panel from an A2UI push target. The earlier article’s generic canvas.render(), canvas.update(), and component-library examples were not a verified SDK and have been removed.

Create a simple widget

On an installation exposing the show_widget tool, ask the agent for a small read-only widget with explicit data:

Create a read-only build-status widget from this data:
commit abc123, checks 8 passed and 1 skipped, deployment not started.
Show the skipped check and deployment state clearly.
Do not fetch external data or start a deployment.

Inspect the actual tool result and rendered content. If the tool is unavailable, use the current show_widget documentation to check the required capability; a prompt alone cannot create a missing tool.

Present on a paired Mac

The documented agent route uses show_widget with presentation.target: "node_panel" when an eligible presenter is available. A connected Mac declaring the required capability is necessary for panel presentation. If presentation fails, inspect whether the widget remained available inline in chat rather than claiming that the Mac panel opened.

The current macOS widget-panel reference documents node commands such as:

openclaw nodes canvas present --node <id>
openclaw nodes canvas hide --node <id>

Replace <id> with the intended paired node. These show or hide a panel; they are not a general-purpose chart-rendering API. Follow the current node and hosted-document instructions for navigation.

Interactive dashboards and A2UI

For interactive A2UI widgets, start with session dashboards. Do not assume that an A2UI action available in a dashboard also works in a native render-only panel. Treat a widget’s display, an interaction event, and the resulting agent action as separate verification steps.

Use explicit sample data first. Add live data or actions only after confirming the target surface and its permissions. A status card saying “deployed” must come from deployment evidence, not from what the widget was asked to draw.

Troubleshooting

Symptom Check before changing settings
Page does not open Gateway service, effective bind/port, and whether localhost is the right machine
Page opens, chat never connects WebSocket connection, Gateway identity, auth, pairing, proxy, and origin
A button seems inactive Live connection, selected scope, permissions, and the action’s visible result
Skills view disagrees with chat Selected agent, skill source/eligibility, and session snapshot
Widget appears inline but not on Mac Connected presenter node and actual presentation result
Old Canvas example fails Current surface and tool contract rather than an obsolete SDK snippet
Mobile differs from desktop Platform capability and the current mobile documentation

For connection details and routing, continue with Gateway concepts. For a missing custom skill, use the SKILL.md development guide.

References

This guide checks current documentation and supplies a small acceptance workflow. It does not claim that a remote Gateway, every dashboard button, or all mobile/Canvas integrations were tested in the author’s environment.

Last updated on Oct 20, 2026 10:23 +0800