OpenClaw setup vs onboard vs configure: the Live Inference Gate, --baseline, and the --reset Flag That Acts Before You Confirm

Switching model providers is an onboard job. configure will add the new models and leave your default exactly where it was.

Search for OpenClaw setup and, past the official reference, you get beginner walkthroughs running roughly 3,500 to 4,800 words each. They cover installing, running openclaw onboard --install-daemon, picking a provider, and connecting Telegram, and they cover it fine. Not one of the three I read mentions openclaw configure. None mention setup --baseline, or what --reset does to your files. The first run is the easy part. Every run after it is a choice between three commands with overlapping flags, and that is what this page sorts out.

Pick by situation

onboard tests the model before it saves anything

openclaw onboard
openclaw onboard --tui
openclaw onboard --classic
openclaw onboard --agent-name robby

Guided onboarding shows a security notice, asks what to call your first agent (it suggests main), and then asks one question about discovery: full access, where it looks for AI apps, keys, and local runtimes on its own, or ask first. Your answer is stored as wizard.accessMode. Detection only builds a list. It doesn't pick a model, and it doesn't save a credential.

You choose a connection and OpenClaw runs a real completion against it. If that fails, you see the error and the picker waits; cancel, and it stops without quietly trying some other provider. Only the verified route and its credential get persisted. This is my favorite thing in the whole setup path, because a mistyped API key now fails in the terminal you are staring at, instead of an hour later as a Telegram message nobody answers.

After the check passes, onboarding looks for memories from Claude Code, Codex, and Hermes and offers to copy them into memory/imports/ in the agent workspace. Nothing moves without a yes. Then it applies the standard workspace, Gateway, and session setup and tries to open the Control UI in your browser, waiting up to 60 seconds for it to connect. Over SSH without a display, or on headless Linux, it prints a dashboard URL (with a port-forward command if the Gateway is on loopback) and waits up to five minutes instead. --tui skips the browser entirely.

Rerunning onboard on a configured install is safe in one specific way. Your current default model shows up in the detected list, and choosing it runs a verification pass that does not re-apply setup or restart the Gateway service. One trap: that check runs outside your workspace, so a model supplied by a workspace plugin can fail here and still work fine inside the agent.

setup is two commands wearing one name

openclaw setup
openclaw setup -m "status"
openclaw setup -m "restart gateway" --yes
openclaw setup --json

On a configured system, bare setup opens an interactive chat with OpenClaw's system agent. On a fresh one it falls through to guided onboarding. And if you pass any onboarding option at all (--wizard, --reset, --flow, an auth flag, a Gateway flag), it runs onboarding exactly as openclaw onboard would. setup --flow quickstart is onboarding under another name.

-m sends one request to the system agent. --yes approves persistent config writes for that one request only. Inside the chat, configure skills, configure web search, and configure gateway run hosted flows, and open gateway wizard hands credential entry to a masked terminal prompt. Gateway changes made this way are config-only. Restart afterward, either with restart gateway in chat or openclaw gateway restart.

--baseline, for scripts

openclaw setup --baseline creates the config, workspace, and session directories and exits. It needs the local Gateway stopped, because it takes exclusive ownership while it creates agent state. It also refuses onboarding, Gateway, auth, reset, or daemon flags outright instead of silently ignoring them, which is the behavior you want in a Dockerfile. If the existing config is invalid, baseline leaves it alone and tells you to run openclaw doctor --fix (the gateway doctor guide covers that). Add --skip-bootstrap to skip generating files like SOUL.md and AGENTS.md; that persists agents.defaults.skipBootstrap: true and sticks on later baseline runs.

Bare openclaw decides for you

Type openclaw with nothing after it in an interactive terminal and it reads your config file to choose: missing or empty starts guided onboarding, present but invalid starts the classic path with doctor guidance, and valid opens the normal agent TUI, where /openclaw gets you back to the setup assistant.

configure is for week two

openclaw configure --section web
openclaw configure --section memory
openclaw configure --section gateway --section daemon

The sections are workspace, model, memory, web, gateway, daemon, channels, plugins, skills, and health. The flag repeats.

It needs a real terminal. With stdin or stdout not a TTY, it prints the equivalent openclaw config get|set|patch|validate commands and exits with an error rather than half-running. Those are what you want in automation anyway, and the config CLI guide walks through them. Before writing, configure also compares the CLI's state and config paths with the ones your installed Gateway service actually uses. A proven mismatch stops the write. It catches a mistake that gets easy once OPENCLAW_HOME is involved: carefully editing a config file the Gateway never reads.

The model section is where the opening line comes from. Re-running provider auth from configure keeps your existing primary model, even when the provider recommends its own default. New models become available; your default doesn't change. To switch on purpose, use openclaw models set <model> (more in the models CLI guide), or run onboard for a new provider route.

The memory section sends a small synthetic embedding request before it saves, so stored OAuth that can't actually embed gets caught. It won't download a local model or rebuild your index. Switching providers drops the old endpoint and key (headers too) so they can't leak to the new destination, and a changed embedding identity may need an explicit reindex afterward.

--reset acts before you can decline

openclaw backup create
openclaw reset --dry-run
openclaw reset --scope config+creds+sessions
openclaw onboard --install-daemon

openclaw onboard --reset exists, and its scopes match openclaw reset: config, config+creds+sessions (the default), and full, which also takes the workspace. One line in the docs should put you off it for good. Interactive classic setup performs the reset before it shows its risk acknowledgement, so your state can already be in the Trash by the time you are offered a chance to say no.

Use the four commands above instead. --dry-run lists every database and session key it would remove, and touches nothing. The sessions scope keeps per-agent database files, since those also hold auth profiles and memory, and your workspace survives everything short of full. Both larger scopes stop a managed Gateway first and print Next: openclaw onboard --install-daemon when they finish cleanly. The backup and migration guide covers restoring if you change your mind. Two more limits: import flags like --import-from hermes can't be combined with --reset, and onboarding reset refuses to run against PostgreSQL storage at all.

Scripted installs: what --accept-risk doesn't cover

export OPENAI_API_KEY="your-provider-key"
export OPENCLAW_GATEWAY_TOKEN="your-token"
openclaw onboard --non-interactive --accept-risk --skip-health \
  --mode local \
  --auth-choice openai-api-key \
  --secret-input-mode ref \
  --gateway-auth token \
  --gateway-token-ref-env OPENCLAW_GATEWAY_TOKEN

--non-interactive requires --accept-risk. That flag does not approve plugin capabilities, so if your provider needs an external plugin such as the Codex runtime, onboarding stops until you run openclaw plugins install codex --accept-capabilities and try again.

Replacing an existing provider credential non-interactively saves the new one inactive and prints a models auth activate command. Your working connection keeps running on the old key, which is polite, and confusing if you were expecting the swap. Also, --json never implies non-interactive. Without a terminal, both guided and classic onboarding return a JSON error. With --secret-input-mode ref, keys land as env references instead of plaintext; the secrets guide explains migrating the plaintext ones you already have.

Final verdict

onboard for anything involving which model answers. configure --section for everything else you would change by hand, and setup when you want to describe the problem in a sentence and let the system agent work out the config. Keep --reset off your fingers entirely. Back up, dry-run, reset, then onboard, and afterward confirm the Gateway is really up with the checks in the status vs health guide.