La configuration des compétences d’OpenClaw

L’essentiel de ce qui décide quelles compétences un agent OpenClaw voit et comment elles s’installent vit sous une clé du fichier de configuration, avec la visibilité par agent sous les entrées d’agents. La page de référence est longue parce que le schéma couvre le chargement, l’installation, le filtrage, le Workshop et une politique d’installation détenue par l’hôte. Voici toute la surface dans l’ordre : chargement et liens symboliques, préférences d’installation, la politique d’installation et sa façon d’échouer fermée, la liste d’autorisation des compétences intégrées et les entrées par compétence, les listes par agent et ce qu’elles ne sont pas, les réglages du Workshop, et le piège du bac à sable.

Charger et installer

• Les répertoires supplémentaires sont parcourus à la priorité la plus basse, sous les compétences intégrées et d’extensions, avec expansion du tilde ; les cibles de liens symboliques de confiance sont les vrais répertoires vers lesquels un dossier de compétence lié peut se résoudre même quand le lien vit hors de la racine configurée, et la documentation dit de garder cette liste étroite plutôt que de la pointer vers un répertoire personnel ; le surveillant, activé par défaut, rafraîchit l’instantané des compétences quand un fichier de compétence change.
• Préférences d’installation : préférer les installateurs Homebrew quand ils existent, un gestionnaire de paquets Node parmi npm, pnpm, yarn et bun qui n’affecte que les installations de compétences, et un interrupteur désactivé par défaut qui laisse les clients administrateurs de confiance installer des archives zip privées préparées par le flux de téléversement.
• La politique d’installation de l’opérateur lance une commande locale de confiance après qu’OpenClaw a préparé la source et avant qu’une installation ou une mise à jour continue, pour les compétences ClawHub, téléversées, Git et locales, les installateurs de dépendances et les sources d’extensions ; elle reçoit un objet JSON décrivant la cible, la source et l’origine et répond autoriser, avertir ou bloquer avec une raison et des constats facultatifs. Activée sans commande valide, les installations échouent fermées, tout comme sur un blocage, une sortie non nulle, un délai dépassé, un JSON invalide ou une raison manquante.
• Un avertissement arrête l’installation avant validation : les commandes interactives demandent à l’opérateur de taper le nom de la cible et relancent la politique, les commandes non interactives peuvent passer une option d’accusé explicite, l’interface de contrôle peut relire les avertissements d’installation d’extensions, les autres installations par la passerelle ou automatiques restent bloquées, et forcer n’approuve jamais un avertissement. Les constats sont plafonnés à cent, l’avis rendu à quatre mille caractères, la vérification approfondie du doctor exécute une sonde d’installation synthétique, et les mises à jour groupées appliquent la politique par cible.

Les listes d’autorisation de compétences par agent sont un filtre de visibilité et de chargement pour la découverte des compétences, les prompts, la découverte des commandes slash, la synchronisation du bac à sable et les instantanés de compétences d’OpenClaw. Elles ne sont pas une frontière d’autorisation au moment du shell.

Entrées et listes d’autorisation

La liste d’autorisation des compétences intégrées ne restreint que celles-ci ; les compétences gérées, d’agent et d’espace de travail ne sont pas affectées. Les entrées par compétence sont indexées par le nom de la compétence, ou par sa clé déclarée : un indicateur d’activation qui désactive une compétence même intégrée ou installée, et qui est ce qui active la compétence d’agent de code facultative une fois une CLI prise en charge installée et connectée ; un champ pratique de clé d’API pour les compétences qui déclarent une variable d’environnement principale, en texte brut ou en référence de secret ; des variables d’environnement injectées pour l’exécution de l’agent seulement quand elles ne sont pas déjà définies dans le processus ; et un sac libre pour des champs personnalisés. La génération d’images intégrée utilise les réglages de modèles de médias et l’outil d’image de base plutôt qu’une entrée. Les listes d’autorisation par agent donnent aux mêmes racines de machine et d’espace de travail un ensemble visible différent par agent : une base partagée sous les valeurs par défaut, héritée par les agents qui omettent leur propre liste, et des listes explicites qui remplacent entièrement les valeurs par défaut, une liste vide n’exposant aucune compétence. L’avertissement compte : si un agent peut lancer exec sur l’hôte, ce shell peut encore lancer des clients externes et lire les fichiers de l’hôte visibles par l’utilisateur d’exécution, registres de clients MCP compris, donc l’isolation par agent exige un bac à sable ou une isolation par utilisateur système, un exec refusé ou strictement listé, et des identifiants par agent au niveau du serveur MCP.

Workshop, liens symboliques, bacs à sable

• Réglages du Workshop : un mode autonome off, propose ou auto, où auto, le défaut, utilise les outils d’agent normaux pour la maintenance directe par tour et hebdomadaire sans analyse de propositions tandis que propose crée des propositions en attente à partir des corrections et du travail substantiel accompli ; une politique d’approbation auto ou en attente ; un maximum de cinquante propositions en attente et en quarantaine par agent dans une plage de un à deux cents ; et un corps de proposition maximal de quarante mille octets dans une plage d’environ mille à deux cent mille, les descriptions étant plafonnées à 160 octets.
• Les racines de compétences d’espace de travail, d’agent de projet, de répertoires supplémentaires et intégrées sont des frontières de confinement, si bien qu’un dossier de compétence lié qui se résout hors de sa racine est ignoré avec une ligne de journal sauf si sa cible est de confiance ; les répertoires de compétences gérées et personnelles acceptent les liens de répertoires sans condition, et le Workshop utilise le répertoire de confinement propre à chaque agent, ignore la liste des cibles de confiance et rejette les liens qui s’en échappent.
• Les valeurs d’environnement et de clé d’API par compétence ne s’appliquent qu’aux exécutions sur l’hôte : dans un bac à sable elles n’ont aucun effet, donc une compétence qui dépend d’une clé échoue avec une erreur de clé non configurée sauf si le bac à sable reçoit la variable séparément par l’environnement du bac à sable Docker, et les utilisateurs ayant accès au démon Docker peuvent lire ces valeurs dans les métadonnées des conteneurs, donc un fichier de secret monté ou une image personnalisée est la réponse quand cette exposition est inacceptable.

L’auto-apprentissage d’OpenClaw explique les règles d’éligibilité et de confidentialité derrière le mode autonome, et Créer une compétence OpenClaw le fichier que le chargeur surveille.

Pourquoi la note sur la frontière compte

Le schéma mélange des contrôles de visibilité et des contrôles de sécurité, et la documentation prend soin de dire lesquels sont lesquels : les listes d’autorisation façonnent ce qui est proposé à l’agent, la politique d’installation façonne ce qui peut être installé, et seuls le bac à sable ou la séparation par utilisateur système façonnent ce qu’un shell peut atteindre. Le bac à sable d’OpenClaw expliqué est cette dernière couche, et Les extensions d’OpenClaw la surface d’installation voisine que la politique couvre aussi.

Sur Diali

Sur Diali, le hub de compétences du tableau de bord est la façade de ce fichier : activer une compétence et coller sa clé est ce qui devient l’entrée sur l’assistant, et il n’y a pas de shell d’hôte pour l’éditer à la main. OpenClaw hébergé sur Diali est l’assistant et La sécurité chez Diali décrit la frontière autour de chacun.

• Les listes d’autorisation remplacent ; elles ne fusionnent jamais.
• La politique d’installation échoue fermée sur tout sauf une autorisation nette.
• Les variables des compétences s’arrêtent au mur du bac à sable.