Aller au contenu
OpenClaw Docs

Référence de configuration CLI

Référence de configuration CLI

Section intitulée « Référence de configuration CLI »

Cette page est la référence complète pour openclaw onboard. Pour le guide court, consultez Onboarding (CLI).

Ce que fait l’assistant

Section intitulée « Ce que fait l’assistant »

Le mode local (par défaut) vous guide à travers :

  • Configuration du modèle et de l’authentification (abonnement Code OpenAI OAuth, clé Anthropic ou jeton de configuration API, ainsi que les options MiniMax, GLM, Ollama, Moonshot et AI Gateway)
  • Emplacement de l’espace de travail et fichiers d’amorçage
  • Paramètres Gateway (port, liaison, auth, tailscale)
  • Canaux et fournisseurs (Telegram, WhatsApp, Discord, Google Chat, plugin Mattermost, Signal)
  • Installation du démon (LaunchAgent ou unité utilisateur systemd)
  • Contrôle de santé
  • Configuration des Skills

Le mode distant configure cette machine pour se connecter à une passerelle ailleurs. Il n’installe ni ne modifie quoi que ce soit sur l’hôte distant.

Détails du flux local

Section intitulée « Détails du flux local »

  1. Détection de la configuration existante

    • Si ~/.openclaw/openclaw.json existe, choisissez Conserver, Modifier ou Réinitialiser.
    • Relancer l’assistant n’efface rien à moins que vous ne choisissiez explicitement Réinitialiser (ou que vous passiez --reset).
    • CLI --reset par défaut est 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 obsolètes, l’assistant s’arrête et vous demande d’exécuter openclaw doctor avant de continuer.
    • La réinitialisation utilise trash et propose des portées :
      • Configuration uniquement
      • Configuration + identifiants + sessions
      • Réinitialisation complète (supprime également l’espace de travail)

  2. Modèle et authentification

  3. Workspace

    • Par défaut ~/.openclaw/workspace (configurable).
    • Initialise les fichiers d’espace de travail nécessaires pour le rituel de bootstrap du premier démarrage.
    • Organisation de l’espace de travail : Espace de travail de l’agent.

  4. Gateway

    • Invite à entrer le port, la liaison, le mode d’authentification et l’exposition Tailscale.
    • Recommandé : gardez l’authentification par jeton activée même pour le bouclage local afin que les clients WS locaux doivent s’authentifier.
    • En mode jeton, la configuration interactive offre :
      • Générer/stocker un jeton en texte clair (par défaut)
      • Utiliser SecretRef (optionnel)
    • En mode mot de passe, la configuration interactive prend également en charge le stockage en texte clair ou SecretRef.
    • Chemin SecretRef de jeton non interactif : `—gateway-token-ref-env

    . - Nécessite une variable d'environnement 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 bouclage local 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 webhook
    • Mattermost plugin : jeton de bot + URL de base
    • Signal : installation facultative de signal-cli + configuration de compte
    • BlueBubbles : recommandé pour iMessage ; URL du serveur + mot de passe + webhook
    • iMessage : chemin du imsg CLI hérité + accès à la base de données
    • Sécurité des DM : la valeur par défaut est le jumelage (pairing). Le premier DM envoie un code ; approuvez via `openclaw pairing approve

    ` ou utilisez des listes d’autorisation (allowlists).

Détails du mode distant

Section intitulée « Détails du mode distant »

Le mode distant configure cette machine pour se connecter à une passerelle située ailleurs.

Ce que vous définissez :

  • URL de la passerelle distante (ws://...)
  • Jeton si l’authentification de la passerelle distante est requise (recommandé)

Options d’authentification et de modèle

Section intitulée « Options d’authentification et de modèle »
Clé Anthropic API

Utilise ANTHROPIC_API_KEY si présent ou demande une clé, puis l’enregistre pour une utilisation par le démon.

Anthropic Claude CLI

Réutilise une connexion Claude CLI locale sur l’hôte de la passerelle et bascule la sélection du modèle vers claude-cli/....

  • macOS : vérifie l’élément du trousseau “Claude Code-credentials”
  • Linux et Windows : réutilise ~/.claude/.credentials.json si présent

Sur macOS, choisissez “Toujours autoriser” afin que les démarrages launchd ne soient pas bloqués.

Jeton Anthropic (setup-token paste)

Exécutez claude setup-token sur n’importe quelle machine, puis collez le jeton. Vous pouvez le nommer ; vide utilise la valeur par défaut.

Abonnement Code OpenAI (réutilisation Codex CLI)

Si ~/.codex/auth.json existe, l’assistant peut le réutiliser.

Abonnement Code OpenAI (OAuth)

Flux navigateur ; collez code#state.

Définit agents.defaults.model sur openai-codex/gpt-5.4 lorsque le model n’est pas défini ou openai/*.

clé OpenAI API

Utilise OPENAI_API_KEY si présent ou demande une clé, puis stocke les informations d’identification dans les profils d’authentification.

Définit agents.defaults.model sur openai/gpt-5.4 lorsque le modèle est non défini, openai/* ou openai-codex/*.

xAI (Grok) clé API

Demande XAI_API_KEY et configure xAI en tant que fournisseur de modèle.

OpenCode

Demande OPENCODE_API_KEY (ou OPENCODE_ZEN_API_KEY) et vous permet de choisir le catalogue Zen ou Go. URL de configuration : opencode.ai/auth.

Clé API (générique)

Stocke la clé pour vous.

Vercel AI Gateway

Demande AI_GATEWAY_API_KEY. Plus de détails : Vercel AI Gateway.

Cloudflare AI Gateway

Demande l’ID de compte, l’ID de passerelle et CLOUDFLARE_AI_GATEWAY_API_KEY. Plus de détails : Cloudflare AI Gateway.

MiniMax

La configuration est écrite automatiquement. La valeur par défaut hébergée est MiniMax-M2.7. Plus de détails : MiniMax.

Synthétique (compatible Anthropic)

Demande SYNTHETIC_API_KEY. Plus de détails : Synthétique.

Ollama (Cloud et modèles open locaux)

Demande l’URL de base (par défaut http://127.0.0.1:11434), puis propose le mode Cloud + Local ou Local. Détecte les modèles disponibles et suggère des valeurs par défaut. Plus de détails : Ollama.

Moonshot et Kimi Coding

Les configurations Moonshot (Kimi K2) et Kimi Coding sont écrites automatiquement. Pour plus de détails : Moonshot AI (Kimi + Kimi Coding).

Custom provider

Fonctionne avec les points de terminaison compatibles OpenAI et Anthropic.

L’onboarding interactif prend en charge les mêmes options de stockage de clé API que les autres flux de clés API de provider :

  • Coller la clé API maintenant (en clair)
  • Utiliser une référence secrète (réf. env ou réf. provider configurée, avec validation préalable)

Indicateurs non interactifs :

  • --auth-choice custom-api-key
  • --custom-base-url
  • --custom-model-id
  • --custom-api-key (facultatif ; revient à CUSTOM_API_KEY)
  • --custom-provider-id (facultatif)
  • `—custom-compatibility

(facultatif ; par défautopenai`)

Skip

Laisse l’auth non configurée.

Comportement du modèle :

  • Choisit le modèle par défaut parmi les options détectées, ou entre le provider et le modèle manuellement.
  • L’assistant exécute une vérification du modèle et avertit si le modèle configuré est inconnu ou si l’auth est manquante.

Chemins des identifiants et des profils :

  • Identifiants OAuth : ~/.openclaw/credentials/oauth.json
  • Profils d’authentification (clés API + OAuth) : ~/.openclaw/agents/<agentId>/agent/auth-profiles.json

Mode de stockage des informations d’identification :

  • Le comportement d’onboarding par défaut enregistre les clés API en tant que valeurs en clair dans les profils d’auth.
  • --secret-input-mode ref active le mode référence au lieu du stockage de clé en texte brut. Dans la configuration interactive, vous pouvez choisir :
    • référence de variable d’environnement (par exemple keyRef: { source: "env", provider: "default", id: "OPENAI_API_KEY" })
    • référence de fournisseur configurée (file ou exec) avec l’alias et l’identifiant du fournisseur
  • Le mode référence interactif exécute une validation préliminaire rapide avant l’enregistrement.
    • Réf Env : valide le nom de la variable + la valeur non vide dans l’environnement d’onboarding actuel.
    • Réf Provider : valide la configuration du provider et résout l’identifiant demandé.
    • Si la validation préliminaire échoue, l’onboarding affiche l’erreur et vous permet de réessayer.
  • En mode non interactif, --secret-input-mode ref est uniquement basé sur l’environnement.
    • Définissez la variable d’environnement du provider dans l’environnement du processus d’onboarding.
    • Les indicateurs de clé en ligne (par exemple --openai-api-key) nécessitent que cette variable d’environnement soit définie ; sinon, l’onboarding échoue rapidement.
    • Pour les fournisseurs personnalisés, le mode non interactif ref stocke models.providers.<id>.apiKey en tant que { source: "env", provider: "default", id: "CUSTOM_API_KEY" }.
    • Dans ce cas de fournisseur personnalisé, --custom-api-key exige que CUSTOM_API_KEY soit défini ; sinon, l’onboarding échoue rapidement.
  • Les identifiants d’authentification Gateway prennent en charge les choix en texte clair et SecretRef dans la configuration interactive :
    • Mode Jeton : Générer/stocker le jeton en clair (par défaut) ou Utiliser SecretRef.
    • Mode Mot de passe : en clair ou SecretRef.
  • Chemin SecretRef du jeton non interactif : --gateway-token-ref-env <ENV_VAR>.
  • Les configurations en clair existantes continuent de fonctionner sans modification.

Sorties et éléments internes

Section intitulée « Sorties et éléments internes »

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

  • agents.defaults.workspace
  • agents.defaults.model / models.providers (si Minimax est choisi)
  • tools.profile (l’onboarding local utilise par défaut "coding" s’il n’est pas défini ; les valeurs explicites existantes sont conservées)
  • gateway.* (mode, bind, auth, tailscale)
  • session.dmScope (l’onboarding local définit cela par défaut à per-channel-peer s’il n’est pas défini ; les valeurs explicites existantes sont conservées)
  • 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 si possible)
  • skills.install.nodeManager
  • wizard.lastRunAt
  • wizard.lastRunVersion
  • wizard.lastRunCommit
  • wizard.lastRunCommand
  • wizard.lastRunMode

openclaw agents add écrit agents.list[] et bindings en option.

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

Assistant de l’Gateway RPC :

  • wizard.start
  • wizard.next
  • wizard.cancel
  • wizard.status

Les clients (application macOS et Interface de contrôle) peuvent afficher les étapes sans réimplémenter la logique d’onboarding.

Comportement de configuration Signal :

  • Télécharge l’actif de version approprié
  • Le stocke sous ~/.openclaw/tools/signal-cli/<version>/
  • Écrit channels.signal.cliPath dans la configuration
  • Les versions JVM nécessitent Java 21
  • Les versions natives sont utilisées lorsqu’elles sont disponibles
  • Windows utilise WSL2 et suit le flux signal-cli Linux à l’intérieur de WSL

Documentation connexe

Section intitulée « Documentation connexe »