Onboard a provider without leaking its credential

Verifiedon 2026-07-302026.7.1-2

Treat provider setup as a boundary decision

Guided onboarding is the supported route for a first configuration. The CLI reference says plain openclaw onboard starts the guided flow; it can select a provider, perform a live inference check, and install a daemon when requested. A failed live check is a stop signal, not an invitation to lower the boundary or copy a key into a config file.

Lab: one provider, one revocable test credential

1. Create a provider credential with a fixed test budget and no broad business access.
2. Start openclaw onboard and choose exactly one provider path.
3. Prefer the onboarding secret-reference option where it is supported. The primary secrets documentation explains that SecretRefs avoid persisting supported credentials as plaintext configuration values, but are not process isolation.
4. Complete the live provider check. Record only pass/fail, provider name, model identifier, time, and the version—never the credential or raw response.

What not to do

Do not add keys to a repository .env, a workspace instruction file, a screenshot, a shared terminal recording, or a support ticket. Do not mistake redaction for revocation: if a credential appears in any readable place, revoke it and create a new test credential.

Scenario check

A screenshot of onboarding accidentally reveals the first characters of a key. What is the next action? Revoke and replace the key, remove the image from every destination you control, and repeat the check with a redacted capture. Editing the screenshot alone does not prove the original is inaccessible.