`openclaw onboard`

Interaktiver Onboarding-Assistent (lokales oder Remote-Gateway-Setup).

Beispiele

openclaw onboard
openclaw onboard --flow quickstart
openclaw onboard --flow manual
openclaw onboard --mode remote --remote-url wss://gateway-host:18789

Für Klartext-ws://-Ziele in privaten Netzwerken (nur vertrauenswürdige Netzwerke) setze OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1 in der Umgebung des Onboarding-Prozesses.

Nicht-interaktiver benutzerdefinierter Provider:

openclaw onboard --non-interactive \
  --auth-choice custom-api-key \
  --custom-base-url "https://llm.example.com/v1" \
  --custom-model-id "foo-large" \
  --custom-api-key "$CUSTOM_API_KEY" \
  --secret-input-mode plaintext \
  --custom-compatibility openai

--custom-api-key ist im nicht-interaktiven Modus optional. Wenn weggelassen, prüft das Onboarding CUSTOM_API_KEY.

Nicht-interaktives Ollama:

openclaw onboard --non-interactive \
  --auth-choice ollama \
  --custom-base-url "http://ollama-host:11434" \
  --custom-model-id "qwen3.5:27b" \
  --accept-risk

--custom-base-url hat den Standardwert http://127.0.0.1:11434. --custom-model-id ist optional; wenn weggelassen, verwendet das Onboarding die von Ollama vorgeschlagenen Standards. Cloud-Modell-IDs wie kimi-k2.5:cloud funktionieren hier ebenfalls.

Provider-Keys als Referenzen statt Klartext speichern:

openclaw onboard --non-interactive \
  --auth-choice openai-api-key \
  --secret-input-mode ref \
  --accept-risk

Mit --secret-input-mode ref schreibt das Onboarding umgebungsbasierte Referenzen anstelle von Klartext-Schlüsselwerten. Für Auth-Profil-basierte Provider werden keyRef-Einträge geschrieben; für benutzerdefinierte Provider wird models.providers.<id>.apiKey als Umgebungsreferenz geschrieben (zum Beispiel { source: "env", provider: "default", id: "CUSTOM_API_KEY" }).

Nicht-interaktiver ref-Modus-Vertrag:

Setze die Provider-Umgebungsvariable in der Onboarding-Prozessumgebung (zum Beispiel OPENAI_API_KEY).
Übergib keine Inline-Key-Flags (zum Beispiel --openai-api-key), es sei denn, die Umgebungsvariable ist ebenfalls gesetzt.
Wenn ein Inline-Key-Flag ohne die erforderliche Umgebungsvariable übergeben wird, bricht das Onboarding mit einer Fehlermeldung ab.

Gateway-Token-Optionen im nicht-interaktiven Modus:

--gateway-auth token --gateway-token <token> speichert ein Klartext-Token.
--gateway-auth token --gateway-token-ref-env <name> speichert gateway.auth.token als Umgebungs-SecretRef.
--gateway-token und --gateway-token-ref-env schließen sich gegenseitig aus.
--gateway-token-ref-env erfordert eine nicht-leere Umgebungsvariable in der Onboarding-Prozessumgebung.
Mit --install-daemon: Wenn Token-Auth ein Token erfordert, werden SecretRef-verwaltete Gateway-Tokens validiert, aber nicht als aufgelöster Klartext in den Service-Umgebungsmetadaten des Supervisors persistiert.
Mit --install-daemon: Wenn der Token-Modus ein Token erfordert und das konfigurierte Token-SecretRef unaufgelöst ist, bricht das Onboarding geschlossen mit Behebungshinweisen ab.
Mit --install-daemon: Wenn sowohl gateway.auth.token als auch gateway.auth.password konfiguriert sind und gateway.auth.mode nicht gesetzt ist, blockiert das Onboarding die Installation, bis der Modus explizit festgelegt wird.

Beispiel:

export OPENCLAW_GATEWAY_TOKEN="your-token"
openclaw onboard --non-interactive \
  --mode local \
  --auth-choice skip \
  --gateway-auth token \
  --gateway-token-ref-env OPENCLAW_GATEWAY_TOKEN \
  --accept-risk

Nicht-interaktive lokale Gateway-Gesundheitsprüfung:

Sofern du nicht --skip-health übergibst, wartet das Onboarding auf ein erreichbares lokales Gateway, bevor es erfolgreich beendet wird.
--install-daemon startet zuerst den verwalteten Gateway-Installationspfad. Ohne diese Option musst du bereits ein lokales Gateway laufen haben, z.B. openclaw gateway run.
Wenn du in der Automatisierung nur Konfigurations-/Workspace-/Bootstrap-Schreibvorgänge benötigst, verwende --skip-health.
Unter nativem Windows versucht --install-daemon zuerst geplante Tasks und fällt auf ein benutzerbezogenes Startup-Ordner-Login-Element zurück, wenn die Task-Erstellung verweigert wird.

Interaktives Onboarding-Verhalten mit Referenzmodus:

Wähle Use secret reference, wenn du dazu aufgefordert wirst.
Dann wähle entweder:
- Umgebungsvariable
- Konfigurierter Secret-Provider (file oder exec)
Das Onboarding führt eine schnelle Vorabvalidierung durch, bevor die Referenz gespeichert wird.
- Wenn die Validierung fehlschlägt, zeigt das Onboarding den Fehler an und lässt dich es erneut versuchen.

Nicht-interaktive Z.AI-Endpunkt-Optionen:

Hinweis: --auth-choice zai-api-key erkennt jetzt automatisch den besten Z.AI-Endpunkt für deinen Schlüssel (bevorzugt die allgemeine API mit zai/glm-5). Wenn du speziell die GLM-Coding-Plan-Endpunkte möchtest, wähle zai-coding-global oder zai-coding-cn.

# Endpunkt-Auswahl ohne Nachfrage
openclaw onboard --non-interactive \
  --auth-choice zai-coding-global \
  --zai-api-key "$ZAI_API_KEY"

# Andere Z.AI-Endpunkt-Optionen:
# --auth-choice zai-coding-cn
# --auth-choice zai-global
# --auth-choice zai-cn

Nicht-interaktives Mistral-Beispiel:

openclaw onboard --non-interactive \
  --auth-choice mistral-api-key \
  --mistral-api-key "$MISTRAL_API_KEY"

Flow-Hinweise:

quickstart: Minimale Eingabeaufforderungen, generiert automatisch ein Gateway-Token.
manual: Vollständige Eingabeaufforderungen für Port/Bind/Auth (Alias von advanced).
Lokales Onboarding DM-Scope-Verhalten: CLI Onboarding Reference.
Schnellster erster Chat: openclaw dashboard (Control-UI, kein Kanal-Setup).
Benutzerdefinierter Provider: Beliebigen OpenAI- oder Anthropic-kompatiblen Endpunkt anbinden, einschließlich gehosteter Provider, die nicht aufgelistet sind. Verwende Unknown zur automatischen Erkennung.

Häufige Folgebefehle

openclaw configure
openclaw agents add <name>

Hinweis: --json impliziert keinen nicht-interaktiven Modus. Verwende --non-interactive für Skripte.

openclaw onboard

Verwandte Anleitungen

Beispiele

Häufige Folgebefehle

`openclaw onboard`