8310c565e0
* feat(onboarding): add provider sign-in flows * fix(oauth): keep callback compatibility * fix(onboarding): reconcile lost auth outcomes * fix(onboarding): lock auth cancellation at commit * fix(onboarding): close provider auth lifecycle gaps * fix(onboarding): make terminal auth failures dismissable * fix(onboarding): satisfy native app checks * fix(onboarding): reconcile absent auth sessions * fix(onboarding): bound provider auth sessions * fix(onboarding): open provider auth links safely * test(onboarding): use scanner-safe auth fixtures * revert: keep established onboarding auth fixtures * fix(onboarding): close provider auth cancellation gaps * fix(gateway): retain uncollected wizard results * fix(onboarding): bind provider reconciliation attempt * fix(i18n): avoid guessing moved string identities * style(onboarding): normalize remote auth choices efficiently * fix(protocol): refresh optional provider auth choices * test(gateway): cover provider auth dispatch order * refactor(macos): split onboarding setup support * fix(macos): refresh merged native checks
5.2 KiB
summary, read_when, title, sidebarTitle
| summary | read_when | title | sidebarTitle | ||
|---|---|---|---|---|---|
| First-run setup flow for OpenClaw (macOS app) |
|
Onboarding (macOS app) | Onboarding: macOS App |
The macOS app's first-run flow: pick where the Gateway runs, connect a verified AI backend, grant permissions, and hand off to the agent's own bootstrap ritual. For CLI onboarding and a comparison of both paths, see Onboarding Overview.
Security trust model:
- By default, OpenClaw is a personal agent: one trusted operator boundary.
- Shared/multi-user setups need lock-down: split trust boundaries, keep tool access minimal, and follow Security.
- Local onboarding defaults new configs to
tools.profile: "coding"so fresh setups keep filesystem/runtime tools without the unrestrictedfullprofile. - If hooks/webhooks or other untrusted content feeds are enabled, use a strong modern model tier and keep strict tool policy/sandboxing.
Where does the Gateway run?
- This Mac (Local only): onboarding configures auth and writes credentials locally.
- Remote (over SSH/Tailnet): onboarding does not configure local auth;
credentials must already exist on the gateway host. The remote gateway token
field stores the token the macOS app uses to connect to that Gateway;
existing
gateway.remote.tokenSecretRef values are preserved until you replace them. - Configure later: skip setup and leave the app unconfigured.
- Gateway auth mode defaults to
tokeneven for loopback binds, so local WS clients must authenticate. - Setting
gateway.auth.mode: "none"lets any local process connect; use that only on fully trusted machines. - Use a token for multi-machine access or non-loopback binds.
Once the Gateway is ready, onboarding looks for AI access you already have:
a Claude Code or Codex login, or OPENAI_API_KEY /
ANTHROPIC_API_KEY. The best option is tested with a real completion and
only saved after it answers; when a test fails the app automatically tries
the next option and shows why the previous one failed. If several options
are found you can switch between them before continuing.
Gemini CLI remains available for normal agents after setup, but it is not offered here because it cannot enforce the tool-free inference probe.
You can also sign in through the provider's own OAuth or device-pairing flow. The built-in choices include OpenAI/ChatGPT, OpenRouter, GitHub Copilot, Google Gemini CLI, xAI, MiniMax Global and CN, and Chutes. The list comes from the Gateway's active text-inference provider plugins rather than a fixed app list, so another provider can opt in without adding provider-specific macOS code.
The manual key/token picker uses the same provider registry. In every route, the provider supplies its starter model and configuration; OpenClaw verifies the credential with the same live test before storing its auth profile. Next remains locked until one backend has passed, so the first agent chat cannot start without working inference. After that live check passes, Crestodian becomes available to help configure the remaining workspace, Gateway, channels, and other optional features; it is also available later under Settings → Crestodian.
Onboarding requests TCC permissions for: Automation (AppleScript), Notifications, Accessibility, Screen Recording, Microphone, Speech Recognition, Camera, and Location.
After inference passes, Crestodian owns the remaining optional setup and can hand you off to the normal agent chat. Finishing the permission walkthrough opens that same chat; the app does not create a workspace or launch a separate agent setup conversation before Crestodian. See [Bootstrapping](/start/bootstrapping) for what happens on the gateway host during the agent's first real turn.