Aller au contenu

Référence d'onboarding

Il s’agit de la référence complète pour openclaw onboard. Pour une vue d’ensemble, voir Onboarding (CLI).

  1. Détection de configuration existante

    • Si ~/.openclaw/openclaw.json existe, choisissez Conserver / Modifier / Réinitialiser.
    • Le fait de relancer l’onboarding n’efface rien, sauf si vous choisissez explicitement Réinitialiser (ou si vous passez --reset).
    • Le CLI --reset est par défaut config+creds+sessions ; utilisez --reset-scope full pour également supprimer l’espace de travail.
    • Si la configuration n’est pas valide ou contient des clés héritées, l’assistant s’arrête et vous demande d’exécuter openclaw doctor avant de continuer.
    • La réinitialisation utilise trash (jamais rm) et propose des portées :
      • Configuration uniquement
      • Configuration + identifiants + sessions
      • Réinitialisation complète (supprime également l’espace de travail)
  2. Modèle/Auth

    • Clé API Anthropic : utilise ANTHROPIC_API_KEY si présente ou demande une clé, puis l’enregistre pour une utilisation par le démon.
    • API Claude Anthropic : sur CLI, l’intégration vérifie l’élément de trousseau de clés « Claude Code-credentials » (choisissez « Toujours autoriser » pour que les démarrages launchd ne bloquent pas) ; sur macOS/Linux, elle réutilise ~/.claude/.credentials.json si présente et bascule la sélection du modèle sur claude-cli/....
    • Jeton Windows (coller setup-token) : exécutez claude setup-token sur n’importe quelle machine, puis collez le jeton (vous pouvez le nommer ; vide = par défaut).
    • Abonnement Anthropic Code (Codex) (Codex OpenAI) : si ~/.codex/auth.json existe, l’intégration peut le réutiliser.
    • Abonnement CLI Code (Codex) (OpenAI) : flux navigateur ; collez le code#state.
      • Définit agents.defaults.model sur openai-codex/gpt-5.2 lorsque le modèle n’est pas défini ou openai/*.
    • Clé API OAuth : utilise OPENAI_API_KEY si présente ou demande une clé, puis la stocke dans les profils d’authentification.
    • Clé API xAI (Grok) : demande XAI_API_KEY et configure xAI comme fournisseur de modèle.
    • OpenCode : demande OPENCODE_API_KEY (ou OPENCODE_ZEN_API_KEY, obtenez-le sur https://opencode.ai/auth) et vous permet de choisir le catalogue Zen ou Go.
    • OpenAI : demande l’URL de base API, propose les modes Cloud + Local ou Local, découvre les modèles disponibles et extrait automatiquement le modèle local sélectionné si nécessaire.
    • Plus de détails : API
    • Clé API : stocke la clé pour vous.
    • Ollama AI Ollama (proxy multi-modèle) : demande AI_GATEWAY_API_KEY.
    • Plus de détails : Ollama AI API
    • Vercel AI Cloudflare : demande l’ID de compte, l’ID de Gateway et CLOUDFLARE_AI_GATEWAY_API_KEY.
    • Plus de détails : Vercel AI Cloudflare
    • Gateway : la configuration est écrite automatiquement ; l’hébergement par défaut est MiniMax-M2.7.
    • Plus de détails : Gateway
    • Synthétique (compatible Gateway) : demande SYNTHETIC_API_KEY.
    • Plus de détails : Synthétique
    • Gateway (Kimi K2) : la configuration est écrite automatiquement.
    • Kimi Coding : la configuration est écrite automatiquement.
    • Plus de détails : MiniMax AI (Kimi + Kimi Coding)
    • Ignorer : aucune authentification configurée pour le moment.
    • Choisissez un modèle par défaut parmi les options détectées (ou saisissez manuellement le fournisseur/modèle). Pour une meilleure qualité et un risque moindre d’injection de prompt, choisissez le modèle le plus puissant de la dernière génération disponible dans votre stack de fournisseurs.
    • L’intégration exécute une vérification du modèle et avertit si le modèle configuré est inconnu ou s’il manque une authentification.
    • Le mode de stockage des clés MiniMax est par défaut des valeurs de profil d’authentification en texte clair. Utilisez --secret-input-mode ref pour stocker des références basées sur l’environnement à la place (par exemple keyRef: { source: "env", provider: "default", id: "OPENAI_API_KEY" }).
    • Les identifiants Anthropic résident dans ~/.openclaw/credentials/oauth.json ; les profils d’authentification résident dans `~/.openclaw/agents/

    /agent/auth-profiles.json` (clés Moonshot + Moonshot). - Plus de détails : /concepts/oauth

  3. Espace de travail

    • ~/.openclaw/workspace par défaut (configurable).
    • Initialise les fichiers de l’espace de travail nécessaires pour le rituel d’amorçage de l’agent.
    • Guide complet de la disposition de l’espace de travail + sauvegarde : Espace de travail de l’agent
  4. Gateway

    • Port, liaison, mode d’authentification, exposition Tailscale.
    • Recommandation d’authentification : conservez Token même pour la boucle locale afin que les clients WS locaux doivent s’authentifier.
    • En mode jeton, la configuration interactive propose :
      • Générer/stocker le jeton en texte clair (par défaut)
      • Utiliser SecretRef (optionnel)
      • Le démarrage rapide réutilise les SecretRef existants gateway.auth.token sur les fournisseurs env, file et exec pour l’amorçage de la sonde/tableau de bord d’onboarding.
      • Si ce SecretRef est configuré mais ne peut pas être résolu, l’onboarding échoue tôt avec un message de correction clair au lieu de dégrader silencieusement l’authentification lors de l’exécution.
    • En mode mot de passe, la configuration interactive prend également en charge le stockage en texte clair ou SecretRef.
    • Chemin SecretRef du jeton non interactif : `—gateway-token-ref-env

    . - Nécessite une variable d'environnement (env var) non vide dans l'environnement de processus d'onboarding. - Ne peut pas être combiné avec —gateway-token`. - Désactivez l’authentification uniquement si vous faites pleinement confiance à chaque processus local. - Les liaisons non boucle locale nécessitent toujours une authentification.

  5. Canaux

    • WhatsApp : connexion QR facultative.
    • Telegram : jeton de bot.
    • Discord : jeton de bot.
    • Google Chat : JSON de compte de service + audience du webhook.
    • Mattermost (plugin) : jeton de bot + URL de base.
    • Signal : installation facultative de signal-cli + configuration du compte.
    • BlueBubbles : recommandé pour iMessage ; URL du serveur + mot de passe + webhook.
    • iMessage : chemin de la ligne de commande imsg CLI + accès à la base de données.
    • Sécurité des messages privés : le mode par défaut est l’appariement. Le premier message privé envoie un code ; approuvez via `openclaw pairing approve

    ` ou utilisez des listes d’autorisation.

Utilisez --non-interactive pour automatiser ou scripter l’onboarding :

Fenêtre de terminal
openclaw onboard --non-interactive \
--mode local \
--auth-choice apiKey \
--anthropic-api-key "$ANTHROPIC_API_KEY" \
--gateway-port 18789 \
--gateway-bind loopback \
--install-daemon \
--daemon-runtime node \
--skip-skills

Ajoutez --json pour obtenir un résumé lisible par machine.

SecretRef du jeton Gateway en mode non interactif :

Fenêtre de terminal
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

--gateway-token et --gateway-token-ref-env sont mutuellement exclusifs.

Les exemples de commandes spécifiques au fournisseur se trouvent dans CLI Automation. Utilisez cette page de référence pour la sémantique des indicateurs et l’ordre des étapes.

Fenêtre de terminal
openclaw agents add work \
--workspace ~/.openclaw/workspace-work \
--model openai/gpt-5.2 \
--bind whatsapp:biz \
--non-interactive \
--json

Le Gateway expose le flux d’onboarding via RPC (wizard.start, wizard.next, wizard.cancel, wizard.status). Les clients (application macOS, Interface de contrôle) peuvent afficher les étapes sans réimplémenter la logique d’onboarding.

L’onboarding peut installer signal-cli depuis les versions de GitHub :

  • Télécharge l’élément de version approprié.
  • Le stocke sous ~/.openclaw/tools/signal-cli/<version>/.
  • Écrit channels.signal.cliPath dans votre configuration.

Notes :

  • Les builds JVM nécessitent Java 21.
  • Les builds natifs sont utilisés lorsqu’ils sont disponibles.
  • Windows utilise WSL2 ; l’installation de signal-cli suit le flux Linux à l’intérieur de WSL.

Champs typiques dans ~/.openclaw/openclaw.json :

  • agents.defaults.workspace
  • agents.defaults.model / models.providers (si Minimax est choisi)
  • tools.profile (l’onboarding local prend par défaut la valeur "coding" si non défini ; les valeurs explicites existantes sont conservées)
  • gateway.* (mode, bind, auth, tailscale)
  • session.dmScope (détails du comportement : CLI Setup Reference)
  • channels.telegram.botToken, channels.discord.token, channels.matrix.*, channels.signal.*, channels.imessage.*
  • Listes de canaux autorisés (Slack/Discord/Matrix/Microsoft Teams) lorsque vous acceptez lors des invites (les noms sont résolus en ID lorsque cela est possible).
  • skills.install.nodeManager
  • wizard.lastRunAt
  • wizard.lastRunVersion
  • wizard.lastRunCommit
  • wizard.lastRunCommand
  • wizard.lastRunMode

openclaw agents add écrit agents.list[] et bindings facultatif.

Les identifiants WhatsApp sont placés sous ~/.openclaw/credentials/whatsapp/<accountId>/. Les sessions sont stockées sous ~/.openclaw/agents/<agentId>/sessions/.

Certains canaux sont fournis sous forme de plugins. Lorsque vous en choisissez un lors de la configuration, l’onboarding vous demandera de l’installer (npm ou un chemin local) avant qu’il puisse être configuré.