What openclaw onboard actually does, step by step
The setup wizard proves a model works with a real completion before it builds anything else. QuickStart vs Manual, the daemon choice, where files land, and where hatching begins.
openclaw onboard is OpenClaw’s setup wizard. Run plainly on a fresh install, it is inference-first: it shows the security notice, then finds or asks for a working AI model and proves it with a real completion before anything else, so only a verified model route gets saved; then it sets up the workspace and the Gateway, and its Quick start lane ends by opening the dashboard in your browser (Custom setup is the longer lane). Add --classic, or any other setup flag such as --install-daemon, and you get the classic step-by-step wizard instead, with channels, the background daemon and skills, where the live model test is offered but can be skipped. Either takes a few minutes; nothing you skip is lost, because openclaw configure reopens the other settings later, and running openclaw onboard again changes the model.
Why it starts with the model
Everything an agent does runs through a model, so the default flow refuses to build on sand. It detects existing access (configured models, API-key environment variables, a Claude Code or Codex sign-in on the machine, local Ollama or LM Studio servers), tests the one you choose with a live completion, and if nothing turns up, asks you to pick: OpenAI, Anthropic, xAI, Google, or OpenRouter up front, more behind More…, via API key or OAuth sign-in. Only “the verified model route and any credential/plugin state it requires” is persisted, in the docs’ words. (The classic wizard asks for a provider the same way and offers the live test, but a failed or skipped test doesn’t stop it.) If you’re unsure what to pick, the API-key question and the model choice have their own guides.
QuickStart vs Manual: what the easy path decides
The classic wizard’s first real fork worries careful people, and reasonably so, since it isn’t obvious what the quick path hides. Here’s the actual list, as its QuickStart writes it on OpenClaw 2026.9.9: a local Gateway on port 18789, bound to loopback (your machine only), token authentication auto-generated even on loopback, Tailscale exposure off, one agent named main, and the full tool profile, which gives the agent every tool; what it may run without asking is a separate setting, the exec approvals and the sandbox. That’s it: sensible-and-reversible, not hidden-and-permanent. Its Manual path (a.k.a. Advanced) walks every step: mode, workspace, gateway, channels, daemon, skills, with an import flow for moving in from Claude, Codex or Hermes. The guided lanes that plain openclaw onboard opens end differently: Quick start runs the Gateway in your terminal until you press Ctrl+C, and openclaw gateway install keeps it running in the background; Custom setup asks for the agent’s name and the telemetry choice; and guided setup can create a small team in place of one agent (a chief of staff with a researcher, a writer and a reviewer, or openclaw onboard --team). When in doubt: the quick path, then change what bothers you later.
The daemon question, and where things land
openclaw onboard --install-daemon opens the classic wizard and also registers the Gateway as a background service so your agent outlives the terminal window: a LaunchAgent on macOS, a systemd user unit on Linux/WSL2, a Scheduled Task on native Windows. Skip it (--skip-daemon) and the Gateway runs only when you start it, a legitimate choice for try-it-out sessions. As for the perennial does-the-folder-matter question: everything the wizard writes is anchored to your home directory (state in ~/.openclaw, workspace in ~/.openclaw/workspace), so the directory you happen to run onboard from decides nothing.
Where onboarding ends and hatching begins
The wizard’s last acts are starting the Gateway and verifying it’s reachable; Quick start then opens the dashboard for you, and openclaw dashboard reopens it later. But the memorable part of first-run happens after the wizard: on the agent’s first real turn, OpenClaw runs its bootstrapping ritual: a short exchange where the agent asks its name, offers a soul line, seeds its workspace files, and deletes BOOTSTRAP.md so the ritual never repeats. That’s a deliberate boundary worth knowing: onboard builds the machinery, hatching creates the character. On OpenClaw 2 that first turn has a deadline: the nightly memory run (03:00 by default) marks an untouched workspace as set up, and an agent nobody has spoken to by then skips the ritual. (The skill and API-key prompts near the wizard’s end, keys like GOOGLE_PLACES_API_KEY for optional skills, are safely skippable; they gate individual skills, not the agent.)
Docker is a different animal
In the Docker install, you don’t run the wizard yourself. The setup script runs onboarding for you: prompts for provider keys, generates a gateway token into .env, and starts the Gateway via Compose. Poke at a running Docker setup with one-off onboard commands and a temporary onboarding container can report that systemd is unavailable and no Gateway can be found while the real Compose-managed Gateway sits healthy beside it: the throwaway container’s loopback simply isn’t the Gateway’s. It looks like a failed install; it’s actually two containers not sharing a network namespace. Judge a Docker setup by docker compose ps and the dashboard, not by what a one-off container claims.