openclaw dashboard Command Reference

`openclaw dashboard`

Use a temporary, single-use owner pairing link to open the Control UI. Once the handoff completes, that signed browser receives a persistent administrator device credential, which means reopening the dashboard no longer relies on the shared Gateway token. If you start a new handoff in the same browser, it can also fix a device credential that was previously restricted.

openclaw dashboard
openclaw dashboard --no-open
openclaw dashboard --json
openclaw dashboard --yes

--no-open: show the URL without launching a browser.
--json: output a single machine-readable connection object, with no browser launch, clipboard use, prompts, or Gateway startup.
--yes: install or start the Gateway without asking for confirmation when it is needed.

Gateway service and state compatibility

The OpenClaw CLI and the background Gateway service operate as two distinct components. When you see a prompt about service installation, it refers to the background service tied to the currently selected profile, not to a missing CLI. A running Gateway is required for the dashboard, and running it in a terminal works as well.

If a warning about a newer database schema appears, it indicates this build cannot read the existing state. To work with that state, you need a compatible build. To begin with a clean slate, set OPENCLAW_STATE_DIR to a different directory. Installing the background service will not fix a database version mismatch. Refer to database compatibility for details.

Machine-readable output

For desktop integrations and scripts that need the resolved Control UI URL, use --json:

openclaw dashboard --json

The output contains the backward-compatible shared-auth url along with browserUrl, browserBootstrapExpiresAtMs, httpUrl, wsUrl, port, and tokenIncluded. Browser integrations should open browserUrl, while native RPC clients that still require the shared Gateway credential can keep using url. When the Gateway is unavailable or a browser handoff cannot be created, the command returns {"ok":false,"reason":"..."} and exits with a non-zero status. Shared tokens managed by SecretRef are never part of url.

Notes:

Where possible, configured gateway.auth.token SecretRefs are resolved.
browserUrl includes a one-time, ten-minute bootstrap located in the URL fragment. The Control UI removes it right away, associates it with the browser's signed device identity, and retains only the resulting administrator per-device credential. No other browser profile can inherit or reuse that grant.
Follows gateway.tls.enabled: when TLS is enabled, gateways print or open https:// Control UI URLs and communicate over wss://.
For lan or a wildcard custom bind, same-host launches always target loopback, since a wildcard is not a valid browser destination. Plaintext tailnet and custom binds also use 127.0.0.1 to give the browser a secure context; TLS-enabled specific hosts keep the configured address so certificate names line up.
Before delivering an authenticated loopback URL for a specific-interface bind, the command checks the configured interface and confirms that both it and 127.0.0.1 belong to the same Gateway process. If listener ownership is ambiguous, it fails closed with status guidance.
The interactive command displays only the clean base URL; the clipboard or browser launch gets the one-time browserUrl, never the shared token. As a result, SecretRef-managed shared tokens do not appear in terminal output, clipboard history, or browser-launch arguments.
If clipboard or browser delivery fails for a token-authenticated URL, the command logs a safe manual-auth hint that names OPENCLAW_GATEWAY_TOKEN, gateway.auth.token, and the URL fragment key token, without ever printing the token value.
When the shared token cannot be embedded in a URL and clipboard or browser delivery fails, run openclaw dashboard --json and open its short-lived browserUrl within ten minutes.