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, and its design 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: only a verified model route gets saved. With a model working, it sets up the workspace, the Gateway, and optionally channels, the background daemon, and skills. QuickStart takes a few minutes; nothing you skip is lost, because openclaw configure reopens any step later.
Why it starts with the model
Everything an agent does runs through a model, so the wizard refuses to build on sand. It detects existing access (configured models, API-key environment variables, local Ollama or LM Studio servers), tests the first candidate 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. 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 wizard’s first real fork worries careful people, and reasonably so, since it isn’t obvious what QuickStart hides. Here’s the actual list: QuickStart configures a local Gateway on port 18789, bound to loopback (your machine only), token authentication auto-generated even on loopback, and the coding tool profile. That’s it: sensible-and-reversible, not hidden-and-permanent. Manual (a.k.a. Advanced) walks every step instead: mode, workspace, gateway, channels, daemon, skills. There’s also an import flow for moving in from another harness. When in doubt: QuickStart, then change what bothers you later.
The daemon question, and where things land
openclaw onboard --install-daemon 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. From there, openclaw dashboard gets you a chat. 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. One first-hand note for anyone poking at a running Docker setup with one-off onboard commands: we’ve watched a temporary onboarding container report that systemd was unavailable and no Gateway could be found while the real Compose-managed Gateway sat 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.