OpenClaw Onboarding Guide

Onboarding turns an installed CLI into a usable personal agent. Complete one model connection and one local Gateway before adding channels, plugins, or remote access.

Run the guided setup

For a normal local installation, run:

openclaw onboard --install-daemon

The wizard asks where the Gateway runs, which model provider to use, and whether the background service should be installed. Provider credentials are evaluated on the Gateway host, so a remote Gateway must already have access to the required secret or login profile.

Use the default personal-agent trust boundary unless you are deliberately building a shared installation. A shared Gateway requires narrower tools, separate agents, explicit sender policy, and stronger isolation.

Connect one model

Choose one provider and let onboarding perform its connection check. Adding credentials does not make an untested provider route useful; the first direct completion should succeed before you continue.

After onboarding, inspect the route:

openclaw models status
openclaw status --all

Do not configure several providers at once. If authentication fails, keep the first model selected and fix that route before adding fallback models.

Verify the Gateway and first chat

openclaw doctor
openclaw gateway status
openclaw dashboard

The dashboard command opens the local Control UI and can provide the owner browser with the required pairing handoff.

Expected result

• Doctor reports no blocking setup error.
• Gateway status reports a running service and successful connectivity probe.
• The Control UI connects without an authentication loop.
• A short direct message receives a model response.

Add a channel only after this local path works. That separation makes later Telegram, Discord, or WhatsApp failures much easier to identify.