OpenClaw Onboarding Guide: How to Use the CLI Wizard Without Getting Lost

If you want the short answer, OpenClaw onboarding is the guided CLI flow that sets up your Gateway, model auth, workspace defaults, channels, and daemon in the right order. Run openclaw onboard, choose QuickStart if you want the fastest path, choose Advanced only if you need extra control, then confirm the result with openclaw gateway status and openclaw dashboard.

That is the easiest way to get from installed to actually usable.

A lot of people get tripped up here because they treat onboarding like a boring setup screen. It is not. In OpenClaw, onboarding is the point where the system stops being a pile of possibilities and becomes a working assistant with a real home, a model, a Gateway, and a first path to chat.

If you have already read How to Install OpenClaw, think of this guide as the next layer down. Installation gets the CLI onto the machine. Onboarding turns that install into a system you can actually trust.

What OpenClaw onboarding actually configures

According to the official Onboarding docs, the CLI flow walks through the core setup steps in order:

• model and auth selection
• workspace location
• Gateway settings
• channels
• daemon installation
• health check
• skills

That order matters more than it looks.

It means you are not guessing which file to touch first. You are letting the product guide you through the dependencies in a sane sequence. That is why onboarding is the right move for most first-time users, even if you are comfortable editing config by hand later.

The docs also call out a useful detail for local setups: when DM isolation is unset, onboarding writes a per-channel-peer default. That is a small thing, but it points to the bigger lesson. Onboarding is not just collecting answers. It is making safe setup decisions for you when the tradeoff is already well understood.

Before you run onboarding

Keep the preflight simple.

You need:

• the OpenClaw CLI already installed
• a supported Node version, with Node 24 recommended and Node 22.14+ supported
• an API key or auth method for the model provider you want to use
• a clear idea of whether you are setting up a local Gateway or connecting to a remote one

If you are still at the installation stage, start with How to Install OpenClaw. If you already have a working install and want to understand the config file behind it, read OpenClaw Configuration Guide next.

QuickStart vs Advanced

One of the best choices in the onboarding flow is that it starts by asking how much control you want right now.

QuickStart is right when you want a first win fast

The docs describe QuickStart as the defaults path. That usually means:

• local Gateway
• default or existing workspace
• default port 18789
• token auth
• practical defaults for tools and DM isolation
• a short path to the Control UI

If your goal is to get to a first live conversation in the next few minutes, this is the lane to pick.

Advanced is right when you already know what you are changing

Advanced is not better. It is just more specific.

Use it when you need to make deliberate choices about:

• remote Gateway connection
• custom workspace paths
• channel selection during setup
• daemon behavior
• skill setup
• tighter control over auth and exposure

A good rule is simple. If you cannot name the setting you need, you probably do not need Advanced yet.

Local mode versus remote mode

This is one of the most important distinctions in the whole flow.

The onboarding docs say local mode configures the local Gateway and walks you through the normal first-run setup. Remote mode only configures the local client to connect to a Gateway somewhere else. It does not install or modify the remote host for you.

That catches people all the time.

If you are running OpenClaw on your own laptop or server, local mode is usually correct.

If your Gateway already lives on another machine and you are only wiring up a client to reach it, remote mode makes sense.

The mistake is assuming remote mode is a remote installer. It is not. It is a connection setup path.

Step by step: how to use openclaw onboard

Step 1: run the command

For a normal interactive setup, start here:

openclaw onboard

If you also want the daemon installed during that first pass, the getting started docs show:

openclaw onboard --install-daemon

That is often the cleanest first-run option.

Step 2: choose your model and auth path carefully

This is the first real decision that affects daily reliability.

Pick the provider you actually plan to use, and do not overthink the perfect multi-provider stack on day one. One working model is better than five half-configured ones.

The onboarding docs note that interactive setup can guide API key flows, OAuth, and provider-specific auth paths. For non-interactive runs, there are flags for secret-reference handling too. That is great later. For most people, the win is simply finishing the first model setup cleanly.

Step 3: confirm the workspace

This part looks small, but it is where your assistant gets an office.

Your workspace is where files like AGENTS.md, SOUL.md, HEARTBEAT.md, and memory notes live. If you want the assistant to act consistently, this is not a throwaway choice. It is the foundation for everything that follows.

The best beginner move is to accept a clear default workspace, get the system live, and only then start refining the files inside it. The workspace files guide is the right follow-up once onboarding is complete.

Step 4: configure the Gateway

The onboarding flow also handles the Gateway basics, including port and auth mode. In the docs, the standard local flow centers on port 18789.

That matters because it gives you a simple mental model afterward:

• if the Gateway is up, the assistant can respond
• if the Gateway is down, almost everything feels broken

This is why a clean onboarding finish should always be followed by a quick Gateway check.

openclaw gateway status

Step 5: decide how much channel setup you want right now

OpenClaw can connect to channels like Telegram, Slack, and Discord. That is powerful, but it can also create too many moving parts in the first hour.

My recommendation is to keep the first session narrow. Either set up one channel you know you need, or skip channel expansion until the Control UI works first.

If chat access is your immediate goal, the docs point new users toward the dashboard first because it removes extra channel variables. That is the right instinct. A clean browser chat proves the core loop is healthy.

Step 6: finish with a live check, not a theory

After onboarding, do two concrete things:

openclaw gateway status
openclaw dashboard

If the Gateway is running and the Control UI opens, you are in good shape.

Send one real message. Do not stop at a green-looking setup screen. Make the system answer.

When to rerun onboarding, and when not to

A lot of confusion disappears once you separate three jobs.

Use onboarding when you need to set up or re-establish the whole operating baseline

Good reasons to rerun onboarding:

• first-time setup
• major reconfiguration
• you want the guided flow again because the system drifted
• you need to add the daemon or revisit high-level choices

Use openclaw configure when the core setup is fine and you only need targeted changes

If you already have a working install and just want to adjust config sections, that is usually a configure job, not a full onboarding job.

Use openclaw agents add <name> when you want a separate agent

The onboarding docs also point to openclaw agents add <name> for creating another agent with its own workspace, sessions, and auth profiles. That is the right move when you want a specialist or second assistant, not when you are just fixing the first one.

Common onboarding mistakes

Choosing Advanced because it feels more serious

Usually this just creates more decisions before you have the context to make them well.

Treating remote mode like a remote installer

It only configures the local client to connect. It does not build the remote machine for you.

Skipping the first live chat

A finished wizard is not the same as a finished setup.

Adding too many channels on day one

One live interaction beats three partly configured entry points.

Editing config before you have a baseline

You will move faster if you let onboarding establish the first version of the system, then refine it afterward.

A clean first-day workflow

If you want a low-drama setup sequence, use this order:

1. install the CLI
2. run onboarding
3. verify the Gateway
4. open the dashboard
5. send one message
6. then add the first channel, extra agent, or skill

That sequence pairs well with these follow-up resources:

• Setup Guide
• What Is OpenClaw
• Workspace Files
• Skills
• OpenClaw Dashboard Guide
• OpenClaw Configuration Guide

Official references for this topic:

• Onboarding docs
• Getting started docs
• Dashboard docs
• OpenClaw on GitHub

Final take

The best way to handle OpenClaw onboarding is not to obsess over every option. It is to finish the guided flow, verify the Gateway, open the Control UI, and get to one working conversation as fast as possible.

Once that first conversation works, the rest of the system starts making sense.

FAQ

What does openclaw onboard actually do?

It walks you through the high-level setup for OpenClaw, including model auth, workspace, Gateway settings, channels, daemon setup, health checks, and skills.

Should I use QuickStart or Advanced?

Use QuickStart if you want a first success fast. Use Advanced only when you already know you need custom settings such as remote connection details, tighter auth choices, or a different setup path.

Is onboarding the same thing as installation?

No. Installation gets the CLI onto the machine. Onboarding configures the system so the install becomes a working assistant.

Can I rerun onboarding later?

Yes. The docs explicitly describe it as the recommended setup path and note that rerunning it does not wipe everything unless you choose a reset path. It is reasonable to rerun when the setup drifted or you want the guided flow again.

When should I use openclaw agents add instead?

Use it when you want a second agent with its own workspace, sessions, and auth profiles. Do not use it as a substitute for finishing the first agent's setup properly.

What should I do if onboarding finishes but the system still feels broken?

Run openclaw gateway status, open the dashboard, and send a message. If config or startup issues appear, go straight to OpenClaw Doctor Guide and OpenClaw Health Checks Guide.