Passer au contenu principal

Documentation Index

Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

OpenClaw lit une configuration facultative depuis ~/.openclaw/openclaw.json. Le chemin de configuration actif doit être un fichier ordinaire. Les dispositions openclaw.json fondées sur des liens symboliques ne sont pas prises en charge pour les écritures appartenant à OpenClaw ; une écriture atomique peut remplacer le chemin au lieu de préserver le lien symbolique. Si vous conservez la configuration en dehors du répertoire d’état par défaut, faites pointer OPENCLAW_CONFIG_PATH directement vers le fichier réel. Si le fichier est absent, OpenClaw utilise des valeurs par défaut sûres. Raisons courantes d’ajouter une configuration :
  • Connecter des canaux et contrôler qui peut envoyer des messages au bot
  • Définir les modèles, les outils, le sandboxing ou l’automatisation (cron, hooks)
  • Ajuster les sessions, les médias, le réseau ou l’interface utilisateur
Consultez la référence complète pour chaque champ disponible. Les agents et l’automatisation doivent utiliser config.schema.lookup pour obtenir la documentation exacte au niveau des champs avant de modifier la configuration. Utilisez cette page pour des conseils orientés tâche et la référence de configuration pour la carte plus large des champs et des valeurs par défaut.
Vous débutez avec la configuration ? Commencez avec openclaw onboard pour une configuration interactive, ou consultez le guide Exemples de configuration pour des configurations complètes à copier-coller.

​
Configuration minimale

// ~/.openclaw/openclaw.json
{
  agents: { defaults: { workspace: "~/.openclaw/workspace" } },
  channels: { whatsapp: { allowFrom: ["+15555550123"] } },
}

​
Modifier la configuration

openclaw onboard       # full onboarding flow
openclaw configure     # config wizard

​
Validation stricte

OpenClaw n’accepte que les configurations qui correspondent entièrement au schéma. Les clés inconnues, les types mal formés ou les valeurs invalides font que le Gateway refuse de démarrer. La seule exception au niveau racine est $schema (chaîne), afin que les éditeurs puissent joindre des métadonnées JSON Schema.
openclaw config schema affiche le JSON Schema canonique utilisé par l’interface de contrôle et la validation. config.schema.lookup récupère un seul nœud limité à un chemin, plus les résumés de ses enfants pour les outils d’exploration détaillée. Les métadonnées de documentation title/description des champs sont propagées dans les objets imbriqués, les branches avec joker (*), élément de tableau ([]) et anyOf/ oneOf/allOf. Les schémas de plugins et de canaux d’exécution sont fusionnés lorsque le registre du manifeste est chargé. Lorsque la validation échoue :
  • Le Gateway ne démarre pas
  • Seules les commandes de diagnostic fonctionnent (openclaw doctor, openclaw logs, openclaw health, openclaw status)
  • Exécutez openclaw doctor pour voir les problèmes exacts
  • Exécutez openclaw doctor --fix (ou --yes) pour appliquer les réparations
Le Gateway conserve une copie fiable de la dernière bonne configuration connue après chaque démarrage réussi, mais le démarrage et le rechargement à chaud ne la restaurent pas automatiquement. Si openclaw.json échoue à la validation (y compris la validation locale au plugin), le démarrage du Gateway échoue ou le rechargement est ignoré, et l’exécution courante conserve la dernière configuration acceptée. Exécutez openclaw doctor --fix (ou --yes) pour réparer une configuration préfixée/écrasée ou restaurer la dernière bonne copie connue. La promotion en dernière bonne configuration connue est ignorée lorsqu’un candidat contient des placeholders de secrets masqués tels que ***.

​
Tâches courantes

Chaque canal possède sa propre section de configuration sous channels.<provider>. Consultez la page dédiée du canal pour les étapes de configuration :Tous les canaux partagent le même modèle de politique de DM :
{
  channels: {
    telegram: {
      enabled: true,
      botToken: "123:abc",
      dmPolicy: "pairing",   // pairing | allowlist | open | disabled
      allowFrom: ["tg:123"], // only for allowlist/open
    },
  },
}
Définissez le modèle principal et les solutions de repli facultatives :
{
  agents: {
    defaults: {
      model: {
        primary: "anthropic/claude-sonnet-4-6",
        fallbacks: ["openai/gpt-5.4"],
      },
      models: {
        "anthropic/claude-sonnet-4-6": { alias: "Sonnet" },
        "openai/gpt-5.4": { alias: "GPT" },
      },
    },
  },
}
  • agents.defaults.models définit le catalogue de modèles et sert de liste d’autorisation pour /model ; les entrées provider/* filtrent /model, /models et les sélecteurs de modèles vers les fournisseurs sélectionnés tout en continuant à utiliser la découverte dynamique des modèles.
  • Utilisez openclaw config set agents.defaults.models '<json>' --strict-json --merge pour ajouter des entrées à la liste d’autorisation sans supprimer les modèles existants. Les remplacements simples qui supprimeraient des entrées sont rejetés sauf si vous passez --replace.
  • Les références de modèle utilisent le format provider/model (par exemple anthropic/claude-opus-4-6).
  • agents.defaults.imageMaxDimensionPx contrôle la réduction d’échelle des images de transcript/outils (par défaut 1200) ; des valeurs plus basses réduisent généralement l’utilisation de tokens de vision sur les exécutions riches en captures d’écran.
  • Consultez CLI des modèles pour changer de modèle dans le chat et Basculement de modèle pour la rotation d’authentification et le comportement de repli.
  • Pour les fournisseurs personnalisés/auto-hébergés, consultez Fournisseurs personnalisés dans la référence.
L’accès DM est contrôlé par canal via dmPolicy :
  • "pairing" (par défaut) : les expéditeurs inconnus reçoivent un code d’appairage à usage unique à approuver
  • "allowlist" : uniquement les expéditeurs dans allowFrom (ou le magasin d’autorisation appairé)
  • "open" : autoriser tous les DM entrants (nécessite allowFrom: ["*"])
  • "disabled" : ignorer tous les DM
Pour les groupes, utilisez groupPolicy + groupAllowFrom ou des listes d’autorisation propres au canal.Consultez la référence complète pour les détails par canal.
Les messages de groupe exigent par défaut une mention obligatoire. Configurez les motifs de déclenchement par agent et conservez les réponses visibles dans les salons sur le chemin par défaut de l’outil de message, sauf si vous souhaitez intentionnellement les anciennes réponses finales automatiques :
{
  messages: {
    visibleReplies: "automatic", // set "message_tool" to require message-tool sends everywhere
    groupChat: {
      visibleReplies: "message_tool", // default; use "automatic" for legacy room replies
    },
  },
  agents: {
    list: [
      {
        id: "main",
        groupChat: {
          mentionPatterns: ["@openclaw", "openclaw"],
        },
      },
    ],
  },
  channels: {
    whatsapp: {
      groups: { "*": { requireMention: true } },
    },
  },
}
  • Mentions de métadonnées : @-mentions natives (mention par toucher WhatsApp, @bot Telegram, etc.)
  • Motifs textuels : motifs regex sûrs dans mentionPatterns
  • Réponses visibles : messages.visibleReplies peut exiger des envois par outil de message globalement ; messages.groupChat.visibleReplies remplace ce comportement pour les groupes/canaux.
  • Consultez la référence complète pour les modes de réponse visible, les remplacements par canal et le mode auto-chat.
Utilisez agents.defaults.skills pour une base partagée, puis remplacez-la pour des agents spécifiques avec agents.list[].skills :
{
  agents: {
    defaults: {
      skills: ["github", "weather"],
    },
    list: [
      { id: "writer" }, // inherits github, weather
      { id: "docs", skills: ["docs-search"] }, // replaces defaults
      { id: "locked-down", skills: [] }, // no skills
    ],
  },
}
  • Omettez agents.defaults.skills pour des Skills non restreints par défaut.
  • Omettez agents.list[].skills pour hériter des valeurs par défaut.
  • Définissez agents.list[].skills: [] pour n’avoir aucune Skills.
  • Consultez Skills, Configuration des Skills et la référence de configuration.
Contrôlez l’agressivité avec laquelle le gateway redémarre les canaux qui semblent obsolètes :
{
  gateway: {
    channelHealthCheckMinutes: 5,
    channelStaleEventThresholdMinutes: 30,
    channelMaxRestartsPerHour: 10,
  },
  channels: {
    telegram: {
      healthMonitor: { enabled: false },
      accounts: {
        alerts: {
          healthMonitor: { enabled: true },
        },
      },
    },
  },
}
  • Définissez gateway.channelHealthCheckMinutes: 0 pour désactiver globalement les redémarrages par surveillance de l’état.
  • channelStaleEventThresholdMinutes doit être supérieur ou égal à l’intervalle de vérification.
  • Utilisez channels.<provider>.healthMonitor.enabled ou channels.<provider>.accounts.<id>.healthMonitor.enabled pour désactiver les redémarrages automatiques pour un canal ou un compte sans désactiver le moniteur global.
  • Consultez Vérifications de l’état pour le débogage opérationnel et la référence complète pour tous les champs.
Donnez aux clients locaux plus de temps pour terminer la négociation WebSocket avant authentification sur des hôtes chargés ou peu puissants :
{
  gateway: {
    handshakeTimeoutMs: 30000,
  },
}
  • La valeur par défaut est 15000 millisecondes.
  • OPENCLAW_HANDSHAKE_TIMEOUT_MS conserve la priorité pour les remplacements ponctuels de service ou de shell.
  • Préférez d’abord corriger les blocages de démarrage/boucle d’événements ; ce réglage est destiné aux hôtes sains mais lents pendant l’échauffement.
Les sessions contrôlent la continuité et l’isolation des conversations :
{
  session: {
    dmScope: "per-channel-peer",  // recommended for multi-user
    threadBindings: {
      enabled: true,
      idleHours: 24,
      maxAgeHours: 0,
    },
    reset: {
      mode: "daily",
      atHour: 4,
      idleMinutes: 120,
    },
  },
}
  • dmScope: main (partagé) | per-peer | per-channel-peer | per-account-channel-peer
  • threadBindings: valeurs par défaut globales pour le routage des sessions liées à un fil (Discord prend en charge /focus, /unfocus, /agents, /session idle et /session max-age).
  • Consultez Gestion des sessions pour la portée, les liens d’identité et la politique d’envoi.
  • Consultez la référence complète pour tous les champs.
Exécutez les sessions d’agent dans des environnements d’exécution sandbox isolés :
{
  agents: {
    defaults: {
      sandbox: {
        mode: "non-main",  // off | non-main | all
        scope: "agent",    // session | agent | shared
      },
    },
  },
}
Construisez d’abord l’image - depuis une extraction des sources, exécutez scripts/sandbox-setup.sh, ou depuis une installation npm, consultez la commande docker build intégrée dans Sandboxing § Images et configuration.Consultez Sandboxing pour le guide complet et la référence complète pour toutes les options.
Les notifications push adossées à un relais se configurent dans openclaw.json.Définissez ceci dans la configuration du Gateway :
{
  gateway: {
    push: {
      apns: {
        relay: {
          baseUrl: "https://relay.example.com",
          // Optional. Default: 10000
          timeoutMs: 10000,
        },
      },
    },
  },
}
Équivalent CLI :
openclaw config set gateway.push.apns.relay.baseUrl https://relay.example.com
Ce que cela fait :
  • Permet au Gateway d’envoyer push.test, des relances de réveil et des réveils de reconnexion via le relais externe.
  • Utilise une autorisation d’envoi liée à l’inscription, transmise par l’application iOS appairée. Le Gateway n’a pas besoin d’un jeton de relais valable pour tout le déploiement.
  • Associe chaque inscription adossée au relais à l’identité du Gateway avec lequel l’application iOS a été appairée, afin qu’un autre Gateway ne puisse pas réutiliser l’inscription stockée.
  • Conserve les builds iOS locaux/manuels sur APNs direct. Les envois adossés au relais s’appliquent uniquement aux builds distribués officiels inscrits via le relais.
  • Doit correspondre à l’URL de base du relais intégrée dans le build iOS officiel/TestFlight, afin que le trafic d’inscription et d’envoi atteigne le même déploiement de relais.
Flux de bout en bout :
  1. Installez un build iOS officiel/TestFlight compilé avec la même URL de base de relais.
  2. Configurez gateway.push.apns.relay.baseUrl sur le Gateway.
  3. Appairez l’application iOS au Gateway et laissez les sessions de nœud et d’opérateur se connecter.
  4. L’application iOS récupère l’identité du Gateway, s’inscrit auprès du relais avec App Attest et le reçu de l’application, puis publie la charge utile push.apns.register adossée au relais vers le Gateway appairé.
  5. Le Gateway stocke le handle de relais et l’autorisation d’envoi, puis les utilise pour push.test, les relances de réveil et les réveils de reconnexion.
Notes opérationnelles :
  • Si vous basculez l’application iOS vers un autre Gateway, reconnectez l’application afin qu’elle puisse publier une nouvelle inscription de relais liée à ce Gateway.
  • Si vous livrez un nouveau build iOS pointant vers un autre déploiement de relais, l’application actualise son inscription de relais en cache au lieu de réutiliser l’ancienne origine de relais.
Note de compatibilité :
  • OPENCLAW_APNS_RELAY_BASE_URL et OPENCLAW_APNS_RELAY_TIMEOUT_MS fonctionnent encore comme surcharges temporaires d’environnement.
  • OPENCLAW_APNS_RELAY_ALLOW_HTTP=true reste une échappatoire de développement limitée au local loopback ; ne persistez pas d’URL de relais HTTP dans la configuration.
Consultez Application iOS pour le flux de bout en bout et Flux d’authentification et de confiance pour le modèle de sécurité du relais.
{
  agents: {
    defaults: {
      heartbeat: {
        every: "30m",
        target: "last",
      },
    },
  },
}
  • every: chaîne de durée (30m, 2h). Définissez 0m pour désactiver.
  • target: last | none | <channel-id> (par exemple discord, matrix, telegram ou whatsapp)
  • directPolicy: allow (par défaut) ou block pour les cibles Heartbeat de type DM
  • Consultez Heartbeat pour le guide complet.
{
  cron: {
    enabled: true,
    maxConcurrentRuns: 2, // cron dispatch + isolated cron agent-turn execution
    sessionRetention: "24h",
    runLog: {
      maxBytes: "2mb",
      keepLines: 2000,
    },
  },
}
  • sessionRetention: supprime les sessions d’exécution isolées terminées de sessions.json (par défaut 24h ; définissez false pour désactiver).
  • runLog: élague cron/runs/<jobId>.jsonl par taille et nombre de lignes conservées.
  • Consultez Tâches Cron pour la présentation de la fonctionnalité et des exemples CLI.
Activez les points de terminaison Webhook HTTP sur le Gateway :
{
  hooks: {
    enabled: true,
    token: "shared-secret",
    path: "/hooks",
    defaultSessionKey: "hook:ingress",
    allowRequestSessionKey: false,
    allowedSessionKeyPrefixes: ["hook:"],
    mappings: [
      {
        match: { path: "gmail" },
        action: "agent",
        agentId: "main",
        deliver: true,
      },
    ],
  },
}
Note de sécurité :
  • Traitez tout le contenu des charges utiles hook/webhook comme une entrée non fiable.
  • Utilisez un hooks.token dédié ; ne réutilisez pas le jeton partagé du Gateway.
  • L’authentification des hooks se fait uniquement par en-tête (Authorization: Bearer ... ou x-openclaw-token) ; les jetons dans la chaîne de requête sont rejetés.
  • hooks.path ne peut pas être / ; conservez l’entrée des Webhook sur un sous-chemin dédié comme /hooks.
  • Gardez les indicateurs de contournement du contenu non sécurisé désactivés (hooks.gmail.allowUnsafeExternalContent, hooks.mappings[].allowUnsafeExternalContent), sauf pour un débogage strictement limité.
  • Si vous activez hooks.allowRequestSessionKey, définissez aussi hooks.allowedSessionKeyPrefixes pour borner les clés de session choisies par l’appelant.
  • Pour les agents pilotés par hooks, privilégiez des niveaux de modèles modernes solides et une politique d’outils stricte (par exemple messagerie uniquement, plus sandboxing lorsque c’est possible).
Consultez la référence complète pour toutes les options de mappage et l’intégration Gmail.
Exécutez plusieurs agents isolés avec des espaces de travail et des sessions séparés :
{
  agents: {
    list: [
      { id: "home", default: true, workspace: "~/.openclaw/workspace-home" },
      { id: "work", workspace: "~/.openclaw/workspace-work" },
    ],
  },
  bindings: [
    { agentId: "home", match: { channel: "whatsapp", accountId: "personal" } },
    { agentId: "work", match: { channel: "whatsapp", accountId: "biz" } },
  ],
}
Consultez Multi-Agent et la référence complète pour les règles de liaison et les profils d’accès par agent.
Utilisez $include pour organiser les grandes configurations :
// ~/.openclaw/openclaw.json
{
  gateway: { port: 18789 },
  agents: { $include: "./agents.json5" },
  broadcast: {
    $include: ["./clients/a.json5", "./clients/b.json5"],
  },
}
  • Fichier unique : remplace l’objet contenant
  • Tableau de fichiers : fusion profonde dans l’ordre (le dernier l’emporte)
  • Clés sœurs : fusionnées après les inclusions (remplacent les valeurs incluses)
  • Inclusions imbriquées : prises en charge jusqu’à 10 niveaux de profondeur
  • Chemins relatifs : résolus relativement au fichier qui inclut
  • Écritures appartenant à OpenClaw : lorsqu’une écriture modifie uniquement une section de premier niveau adossée à une inclusion de fichier unique comme plugins: { $include: "./plugins.json5" }, OpenClaw met à jour ce fichier inclus et laisse openclaw.json intact
  • Écriture transparente non prise en charge : les inclusions racine, les tableaux d’inclusions et les inclusions avec des surcharges sœurs échouent de manière fermée pour les écritures appartenant à OpenClaw au lieu d’aplatir la configuration
  • Confinement : les chemins $include doivent se résoudre sous le répertoire contenant openclaw.json. Pour partager une arborescence entre des machines ou des utilisateurs, définissez OPENCLAW_INCLUDE_ROOTS sur une liste de chemins (: sur POSIX, ; sur Windows) de répertoires supplémentaires que les inclusions peuvent référencer. Les liens symboliques sont résolus puis revérifiés, donc un chemin qui réside lexicalement dans un répertoire de configuration mais dont la cible réelle sort de toutes les racines autorisées est toujours rejeté.
  • Gestion des erreurs : erreurs claires pour les fichiers manquants, les erreurs d’analyse et les inclusions circulaires

​
Rechargement à chaud de la configuration

Le Gateway surveille ~/.openclaw/openclaw.json et applique automatiquement les changements - aucun redémarrage manuel n’est nécessaire pour la plupart des paramètres. Les modifications directes de fichier sont considérées comme non fiables jusqu’à validation. Le surveillant attend que les écritures temporaires/renommages de l’éditeur se stabilisent, lit le fichier final et rejette les modifications externes invalides sans réécrire openclaw.json. Les écritures de configuration appartenant à OpenClaw utilisent la même barrière de schéma avant l’écriture ; les écrasements destructeurs comme la suppression de gateway.mode ou la réduction du fichier de plus de moitié sont rejetés et enregistrés sous .rejected.* pour inspection. Si vous voyez config reload skipped (invalid config) ou si le démarrage signale Invalid config, inspectez la configuration, exécutez openclaw config validate, puis exécutez openclaw doctor --fix pour réparation. Consultez Dépannage du Gateway pour la liste de vérification.

​
Modes de rechargement

ModeComportement
hybrid (par défaut)Applique instantanément à chaud les changements sûrs. Redémarre automatiquement pour les changements critiques.
hotApplique à chaud uniquement les changements sûrs. Journalise un avertissement lorsqu’un redémarrage est nécessaire - vous le gérez.
restartRedémarre le Gateway à chaque changement de configuration, sûr ou non.
offDésactive la surveillance des fichiers. Les changements prennent effet au prochain redémarrage manuel.
{
  gateway: {
    reload: { mode: "hybrid", debounceMs: 300 },
  },
}

​
Ce qui s’applique à chaud et ce qui nécessite un redémarrage

La plupart des champs s’appliquent à chaud sans interruption. En mode hybrid, les changements nécessitant un redémarrage sont gérés automatiquement.
CatégorieChampsRedémarrage nécessaire ?
Canauxchannels.*, web (WhatsApp) - tous les canaux intégrés et PluginNon
Agent et modèlesagent, agents, models, routingNon
Automatisationhooks, cron, agent.heartbeatNon
Sessions et messagessession, messagesNon
Outils et médiastools, browser, skills, mcp, audio, talkNon
UI et diversui, logging, identity, bindingsNon
Serveur Gatewaygateway.* (port, bind, auth, tailscale, TLS, HTTP)Oui
Infrastructurediscovery, pluginsOui
gateway.reload et gateway.remote sont des exceptions - les modifier ne déclenche pas de redémarrage.

​
Planification du rechargement

Lorsque vous modifiez un fichier source référencé via $include, OpenClaw planifie le rechargement à partir de la disposition définie dans la source, et non de la vue aplatie en mémoire. Cela rend les décisions de rechargement à chaud (application à chaud ou redémarrage) prévisibles, même lorsqu’une seule section de premier niveau réside dans son propre fichier inclus, comme plugins: { $include: "./plugins.json5" }. La planification du rechargement échoue de manière fermée si la disposition source est ambiguë.

​
RPC de configuration (mises à jour programmatiques)

Pour les outils qui écrivent la configuration via l’API Gateway, privilégiez ce flux :
  • config.schema.lookup pour inspecter un sous-arbre (nœud de schéma superficiel + résumés des enfants)
  • config.get pour récupérer l’instantané actuel avec le hash
  • config.patch pour les mises à jour partielles (correctif de fusion JSON : les objets fusionnent, null supprime, les tableaux remplacent)
  • config.apply uniquement lorsque vous avez l’intention de remplacer toute la configuration
  • update.run pour une auto-mise à jour explicite suivie d’un redémarrage ; incluez continuationMessage lorsque la session après redémarrage doit exécuter un tour de suivi
  • update.status pour inspecter la dernière sentinelle de redémarrage de mise à jour et vérifier la version en cours d’exécution après un redémarrage
Les agents doivent considérer config.schema.lookup comme le premier point d’entrée pour la documentation et les contraintes exactes au niveau des champs. Utilisez la référence de configuration lorsqu’ils ont besoin de la carte de configuration plus large, des valeurs par défaut ou des liens vers les références dédiées des sous-systèmes.
Les écritures du plan de contrôle (config.apply, config.patch, update.run) sont limitées à 3 requêtes par 60 secondes par deviceId+clientIp. Les requêtes de redémarrage sont coalescées, puis imposent un délai de récupération de 30 secondes entre les cycles de redémarrage. update.status est en lecture seule, mais limité à l’administration, car la sentinelle de redémarrage peut inclure des résumés d’étapes de mise à jour et des fins de sortie de commande.
Exemple de correctif partiel : 
openclaw gateway call config.get --params '{}'  # capture payload.hash
openclaw gateway call config.patch --params '{
  "raw": "{ channels: { telegram: { groups: { \"*\": { requireMention: false } } } } }",
  "baseHash": "<hash>"
}'
config.apply et config.patch acceptent tous deux raw, baseHash, sessionKey, note et restartDelayMs. baseHash est requis pour les deux méthodes lorsqu’une configuration existe déjà.

​
Variables d’environnement

OpenClaw lit les variables d’environnement depuis le processus parent ainsi que :
  • .env depuis le répertoire de travail actuel (s’il est présent)
  • ~/.openclaw/.env (solution de repli globale)
Aucun de ces fichiers ne remplace les variables d’environnement existantes. Vous pouvez également définir des variables d’environnement en ligne dans la configuration : 
{
  env: {
    OPENROUTER_API_KEY: "sk-or-...",
    vars: { GROQ_API_KEY: "gsk-..." },
  },
}
Si cette option est activée et que les clés attendues ne sont pas définies, OpenClaw exécute votre shell de connexion et importe uniquement les clés manquantes :
{
  env: {
    shellEnv: { enabled: true, timeoutMs: 15000 },
  },
}
Équivalent en variable d’environnement : OPENCLAW_LOAD_SHELL_ENV=1
Référencez des variables d’environnement dans n’importe quelle valeur de chaîne de configuration avec ${VAR_NAME} :
{
  gateway: { auth: { token: "${OPENCLAW_GATEWAY_TOKEN}" } },
  models: { providers: { custom: { apiKey: "${CUSTOM_API_KEY}" } } },
}
Règles :
  • Seuls les noms en majuscules correspondent : [A-Z_][A-Z0-9_]*
  • Les variables manquantes ou vides déclenchent une erreur au chargement
  • Échappez avec $${VAR} pour une sortie littérale
  • Fonctionne dans les fichiers $include
  • Substitution en ligne : "${BASE}/v1" → "https://api.example.com/v1"
Pour les champs qui prennent en charge les objets SecretRef, vous pouvez utiliser :
{
  models: {
    providers: {
      openai: { apiKey: { source: "env", provider: "default", id: "OPENAI_API_KEY" } },
    },
  },
  skills: {
    entries: {
      "image-lab": {
        apiKey: {
          source: "file",
          provider: "filemain",
          id: "/skills/entries/image-lab/apiKey",
        },
      },
    },
  },
  channels: {
    googlechat: {
      serviceAccountRef: {
        source: "exec",
        provider: "vault",
        id: "channels/googlechat/serviceAccount",
      },
    },
  },
}
Les détails de SecretRef (y compris secrets.providers pour env/file/exec) se trouvent dans Gestion des secrets. Les chemins d’identifiants pris en charge sont listés dans Surface d’identifiants SecretRef.
Consultez Environnement pour la précédence et les sources complètes.

​
Référence complète

Pour la référence complète champ par champ, consultez Référence de configuration.
Associé : Exemples de configuration · Référence de configuration · Doctor

​
Associé