Approbations d’exécution — avancé

Sujets avancés sur l’approbation d’exécution : le chemin rapide safeBins, la liaison des interpréteurs/environnements d’exécution et le transfert des approbations vers les canaux de discussion (y compris la livraison native). Pour la politique principale et le flux d’approbation, consultez Approbations d’exécution.

Binaires sûrs (entrée standard uniquement)

tools.exec.safeBins désigne des binaires limités à l’entrée standard (par exemple cut) qui s’exécutent en mode liste d’autorisation sans entrée explicite dans celle-ci. Les binaires sûrs rejettent les arguments positionnels de fichiers et les jetons ressemblant à des chemins ; ils ne peuvent donc agir que sur le flux entrant. Considérez cela comme un chemin rapide restreint pour les filtres de flux, et non comme une liste générale de confiance.

Binaires sûrs par défaut :

cut, uniq, head, tail, tr, wc

grep et sort ne figurent pas dans la liste par défaut. Si vous les activez, conservez des entrées explicites dans la liste d’autorisation pour leurs utilisations ne reposant pas sur l’entrée standard. Pour grep en mode binaire sûr, fournissez le motif avec -e/--regexp ; la forme positionnelle du motif est rejetée afin d’empêcher la dissimulation d’opérandes de fichiers sous forme d’arguments positionnels ambigus.

Validation d’argv et options interdites

La validation est déterministe et repose uniquement sur la structure d’argv (sans vérifier l’existence de fichiers sur le système hôte), ce qui empêche d’utiliser les différences entre autorisation et refus comme oracle d’existence de fichiers. Les options orientées fichiers sont interdites pour les binaires sûrs par défaut ; la validation des options longues échoue de manière fermée (les options inconnues et les abréviations ambiguës sont rejetées). Les options booléennes reconnues et en lecture seule des binaires par défaut (par exemple wc -l, tr -d, uniq -c) sont acceptées, tandis que les options courtes non reconnues restent refusées par défaut et nécessitent une approbation manuelle.

Options interdites par profil de binaire sûr :

• grep : --dereference-recursive, --directories, --exclude-from, --file, --recursive, -R, -d, -f, -r
• jq : --argfile, --from-file, --library-path, --rawfile, --slurpfile, -L, -f
• sort : --compress-program, --files0-from, --output, --random-source, --temporary-directory, -T, -o
• tail : --follow, --retry, -F, -f
• wc : --files0-from

Les binaires sûrs imposent également que les jetons d’argv soient traités comme du texte littéral lors de l’exécution (sans développement des caractères génériques ni des $VARS) pour les segments limités à l’entrée standard, de sorte que des motifs comme * ou $HOME/... ne puissent pas servir à dissimuler des lectures de fichiers. awk, sed et jq sont toujours refusés comme binaires sûrs, car leur sémantique ne peut pas être validée comme limitée à l’entrée standard : jq peut lire les données d’environnement et charger du code jq depuis des modules ou des fichiers de démarrage. Pour ces outils, utilisez plutôt une entrée explicite dans la liste d’autorisation ou une invite d’approbation que safeBins.

Répertoires de binaires approuvés

Les binaires sûrs doivent être résolus depuis des répertoires de binaires approuvés (valeurs système par défaut, complétées éventuellement par tools.exec.safeBinTrustedDirs). Les entrées de PATH ne sont jamais automatiquement approuvées. Les répertoires approuvés par défaut sont volontairement limités : /bin, /usr/bin. Si l’exécutable de votre binaire sûr se trouve dans des chemins de gestionnaire de paquets ou d’utilisateur (par exemple /opt/homebrew/bin, /usr/local/bin, /opt/local/bin, /snap/bin), ajoutez-les explicitement à tools.exec.safeBinTrustedDirs.

Chaînage de commandes shell, enveloppes et multiplexeurs

Le chaînage de commandes shell (&&, ||, ;) est autorisé lorsque chaque segment de premier niveau satisfait la liste d’autorisation (y compris les binaires sûrs ou l’autorisation automatique par une skill). Les redirections restent non prises en charge en mode liste d’autorisation. La substitution de commande ($() / accents graves) est rejetée lors de l’analyse de la liste d’autorisation, y compris à l’intérieur de guillemets doubles ; utilisez des guillemets simples si vous avez besoin du texte littéral $().

Pour les approbations via l’application compagnon macOS, le texte shell brut contenant une syntaxe de contrôle ou de développement shell (&&, ||, ;, |, `, $, <, >, (, )) est considéré comme ne correspondant pas à la liste d’autorisation, sauf si le binaire shell lui-même y figure.

Pour les enveloppes shell (bash|sh|zsh ... -c/-lc), les substitutions de variables d’environnement limitées à la requête sont réduites à une petite liste d’autorisation explicite (TERM, LANG, LC_*, COLORTERM, NO_COLOR, FORCE_COLOR).

Pour les décisions allow-always en mode liste d’autorisation, les enveloppes de distribution transparentes (par exemple env, flock, nice, nohup, stdbuf, timeout) enregistrent le chemin de l’exécutable interne plutôt que celui de l’enveloppe. Les multiplexeurs shell (busybox, toybox) sont désenveloppés de la même manière pour les applets shell (sh, ash, etc.). Si une enveloppe ou un multiplexeur ne peut pas être désenveloppé en toute sécurité, aucune entrée de liste d’autorisation n’est enregistrée automatiquement.

Si vous ajoutez à la liste d’autorisation des interpréteurs comme python3 ou node, privilégiez tools.exec.strictInlineEval=true afin que l’évaluation en ligne nécessite toujours une approbation explicite. En mode strict, allow-always peut toujours enregistrer des appels bénins d’interpréteur ou de script, mais les vecteurs d’évaluation en ligne ne sont pas enregistrés automatiquement.

Binaires sûrs et liste d’autorisation

Emplacement de la configuration :

• safeBins provient de la configuration (tools.exec.safeBins ou, par agent, agents.list[].tools.exec.safeBins).
• safeBinTrustedDirs provient de la configuration (tools.exec.safeBinTrustedDirs ou, par agent, agents.list[].tools.exec.safeBinTrustedDirs).
• safeBinProfiles provient de la configuration (tools.exec.safeBinProfiles ou, par agent, agents.list[].tools.exec.safeBinProfiles). Les clés de profil propres à un agent remplacent les clés globales.
• Les entrées de la liste d’autorisation se trouvent dans le fichier local d’approbations de l’hôte sous agents.<id>.allowlist (ou via l’interface de contrôle / openclaw approvals allowlist ...).
• openclaw security audit émet l’avertissement tools.exec.safe_bins_interpreter_unprofiled lorsque des binaires d’interpréteur ou d’environnement d’exécution figurent dans safeBins sans profil explicite.
• openclaw doctor --fix peut générer la structure des entrées personnalisées safeBinProfiles.<bin> manquantes sous la forme {} (examinez-les et rendez-les plus restrictives ensuite). Les binaires d’interpréteur ou d’environnement d’exécution ne sont pas générés automatiquement.

Exemple de profil personnalisé : OC_I18N_900000

Commandes d’interpréteur ou d’environnement d’exécution

Les exécutions d’interpréteurs ou d’environnements d’exécution soumises à approbation sont volontairement prudentes :

• Le contexte exact d’argv, du répertoire de travail et de l’environnement est toujours lié.
• Les formes de script shell direct et de fichier d’environnement d’exécution direct sont liées, dans la mesure du possible, à un instantané précis d’un fichier local.
• Les formes courantes d’enveloppes de gestionnaire de paquets qui se résolvent toujours vers un seul fichier local direct (par exemple pnpm exec, pnpm node, npm exec, npx) sont désenveloppées avant la liaison.
• Si OpenClaw ne peut pas identifier exactement un fichier local précis pour une commande d’interpréteur ou d’environnement d’exécution (par exemple des scripts de paquet, des formes d’évaluation, des chaînes de chargeurs propres à l’environnement d’exécution ou des formes ambiguës à plusieurs fichiers), l’exécution soumise à approbation est refusée au lieu de prétendre offrir une couverture sémantique qu’elle ne possède pas.
• Pour ces flux de travail, privilégiez l’exécution en bac à sable, une limite d’hôte distincte ou une liste d’autorisation/un flux de travail complet explicitement approuvé dans lequel l’opérateur accepte la sémantique plus large de l’environnement d’exécution.

Lorsque des approbations sont requises, l’outil d’exécution renvoie immédiatement un identifiant d’approbation. Utilisez cet identifiant pour corréler les événements système ultérieurs de l’exécution approuvée (Exec finished, ainsi que Exec running lorsqu’il est configuré). Si aucune décision n’arrive avant l’expiration du délai, la requête est traitée comme une expiration de l’approbation et signalée comme un refus terminal de la commande hôte. Pour les approbations asynchrones de l’agent principal disposant d’une session d’origine, OpenClaw reprend également cette session avec un suivi interne afin que l’agent constate que la commande ne s’est pas exécutée, au lieu de tenter ultérieurement de réparer un résultat manquant. Les approbations d’exécution en attente expirent par défaut après 30 minutes.

Comportement de livraison du suivi

Après la fin d’une exécution asynchrone approuvée, OpenClaw envoie un tour agent de suivi à la même session. Les approbations asynchrones refusées utilisent le même chemin de suivi de la session principale pour signaler le refus, mais elles n’enregistrent pas de transfert vers un environnement d’exécution élevé et n’exécutent pas la commande. Les refus sans session principale pouvant être reprise sont soit ignorés, soit signalés par une voie directe sûre lorsqu’il en existe une.

• S’il existe une cible de livraison externe valide (canal permettant la livraison et cible to), le suivi est livré via ce canal.
• Dans les flux limités au chat web ou aux sessions internes sans cible externe, la livraison du suivi reste limitée à la session (deliver: false).
• Si un appelant demande explicitement une livraison externe stricte sans canal externe pouvant être résolu, la requête échoue avec INVALID_REQUEST.
• Si bestEffortDeliver est activé et qu’aucun canal externe ne peut être résolu, la livraison est rétrogradée en livraison limitée à la session au lieu d’échouer.

Transfert des approbations vers les canaux de discussion

Vous pouvez transférer les invites d’approbation d’exécution vers n’importe quel canal de discussion (y compris les canaux de Plugin) et les approuver avec /approve. Cette fonctionnalité utilise le pipeline normal de livraison sortante.

Configuration : OC_I18N_900001 Répondez dans le chat : OC_I18N_900002 La commande /approve gère à la fois les approbations d’exécution et celles de Plugin. Si l’identifiant ne correspond à aucune approbation d’exécution en attente, elle vérifie automatiquement les approbations de Plugin à la place. Ce mécanisme de repli est limité aux échecs de type « approbation introuvable » ; un refus ou une erreur réelle d’approbation d’exécution ne déclenche pas silencieusement une nouvelle tentative en tant qu’approbation de Plugin.

Transfert des approbations de Plugin

Le transfert des approbations de Plugin utilise le même pipeline de livraison que les approbations d’exécution, mais dispose de sa propre configuration indépendante sous approvals.plugin. L’activation ou la désactivation de l’un n’affecte pas l’autre. Pour le comportement de création de Plugin, les champs de requête et la sémantique des décisions, consultez Demandes d’autorisation de Plugin. OC_I18N_900003 La structure de configuration est identique à celle de approvals.exec : enabled, mode, agentFilter, sessionFilter et targets fonctionnent de la même manière.

Les canaux qui prennent en charge les réponses interactives partagées affichent les mêmes boutons d’approbation pour les approbations d’exécution et de Plugin. Les canaux dépourvus d’interface utilisateur interactive partagée utilisent à la place du texte brut avec des instructions /approve. Les demandes d’approbation de Plugin peuvent restreindre les décisions disponibles : les interfaces d’approbation utilisent l’ensemble de décisions déclaré par la demande, et le Gateway rejette toute tentative d’envoyer une décision qui n’a pas été proposée.

Approbations dans la même conversation sur n’importe quel canal

Lorsqu’une demande d’approbation d’exécution ou de Plugin provient d’une interface de conversation permettant la remise des messages, cette même conversation peut l’approuver avec /approve par défaut. Cela s’applique à Slack, Matrix, Microsoft Teams et aux conversations similaires permettant la remise des messages, en plus des flux existants de l’interface Web et de l’interface de terminal, en utilisant le modèle d’authentification normal du canal pour cette conversation. Si la conversation d’origine peut déjà envoyer des commandes et recevoir des réponses, les demandes d’approbation n’ont plus besoin d’un adaptateur de remise natif distinct uniquement pour rester en attente.

Discord, Telegram et QQ bot prennent également en charge /approve dans la même conversation, mais ces canaux utilisent toujours leur liste d’approbateurs résolue pour l’autorisation, même lorsque la remise native des approbations est désactivée.

Remise native des approbations

Certains canaux peuvent également agir comme clients d’approbation natifs : Discord, Slack, Telegram, Matrix et QQ bot. Les clients natifs ajoutent les messages privés aux approbateurs, la diffusion vers la conversation d’origine et une expérience d’approbation interactive propre au canal, en complément du flux partagé /approve dans la même conversation.

Lorsque des cartes ou boutons d’approbation natifs sont disponibles, cette interface native constitue le principal parcours destiné à l’agent. L’agent ne doit pas également répéter une commande /approve en texte brut dans la conversation, sauf si le résultat de l’outil indique que les approbations par conversation sont indisponibles ou que l’approbation manuelle est la seule possibilité restante.

Si un client d’approbation natif est configuré, mais qu’aucun environnement d’exécution natif n’est actif pour le canal d’origine, OpenClaw conserve l’invite locale déterministe /approve visible. Si l’environnement d’exécution natif est actif et tente la remise, mais qu’aucune cible ne reçoit la carte, OpenClaw envoie une notification de repli dans la même conversation avec la commande exacte /approve <id> <decision> afin que la demande puisse toujours être traitée.

Modèle générique :

• la politique d’exécution de l’hôte détermine toujours si une approbation d’exécution est requise
• approvals.exec contrôle le transfert des invites d’approbation vers d’autres destinations de conversation
• channels.<channel>.execApprovals détermine si les clients natifs propres à Discord, Slack, Telegram, QQ bot et aux canaux similaires sont activés
• les approbations de Plugin Slack peuvent utiliser le client d’approbation natif de Slack lorsque la demande provient de Slack et que les approbateurs de Plugin Slack sont résolus ; approvals.plugin peut également acheminer les approbations de Plugin vers des sessions ou cibles Slack, même lorsque les approbations d’exécution Slack sont désactivées
• les cartes d’approbation natives de Google Chat gèrent les approbations d’exécution et de Plugin provenant d’espaces ou de fils de discussion Google Chat lorsque des approbateurs stables users/<id> sont résolus à partir de dm.allowFrom ou defaultTo ; elles n’utilisent pas les événements de réaction pour les décisions
• la remise des approbations par réaction dans WhatsApp et Signal est contrôlée par approvals.exec et approvals.plugin ; ces canaux ne comportent pas de blocs channels.<channel>.execApprovals

Les clients d’approbation natifs activent automatiquement la remise prioritaire par message privé lorsque toutes les conditions suivantes sont remplies :

• le canal prend en charge la remise native des approbations
• les approbateurs peuvent être résolus à partir de execApprovals.approvers explicites ou de l’identité du propriétaire, telle que commands.ownerAllowFrom
• channels.<channel>.execApprovals.enabled n’est pas défini ou vaut "auto"

Définissez enabled: false pour désactiver explicitement un client d’approbation natif. Définissez enabled: true pour forcer son activation lorsque les approbateurs sont résolus. La remise publique dans la conversation d’origine reste explicitement contrôlée par channels.<channel>.execApprovals.target. Lorsque la valeur native target active la remise dans la conversation d’origine, les invites d’approbation incluent le texte de la commande.

FAQ : Pourquoi existe-t-il deux configurations d’approbation d’exécution pour les approbations par conversation ?

• Discord : channels.discord.execApprovals.*
• Slack : channels.slack.execApprovals.*
• Telegram : channels.telegram.execApprovals.*
• QQ bot : channels.qqbot.execApprovals.*
• Google Chat : configurez des approbateurs stables avec channels.googlechat.dm.allowFrom ou channels.googlechat.defaultTo ; aucun bloc execApprovals n’est requis
• WhatsApp : utilisez approvals.exec et approvals.plugin pour acheminer les invites d’approbation vers WhatsApp
• Signal : utilisez approvals.exec et approvals.plugin pour acheminer les invites d’approbation vers Signal

Acheminement propre aux clients natifs :

• Telegram utilise par défaut les messages privés aux approbateurs (target: "dm"). Passez à channel ou both pour également afficher les invites d’approbation dans la conversation ou le sujet Telegram d’origine. Pour les sujets de forum Telegram, OpenClaw conserve le sujet pour l’invite d’approbation et le suivi après approbation.
• Les approbateurs Discord et Telegram peuvent être explicites (execApprovals.approvers) ou déduits de commands.ownerAllowFrom ; seuls les approbateurs résolus peuvent approuver ou refuser.
• Les approbateurs Slack peuvent être explicites (execApprovals.approvers) ou déduits de commands.ownerAllowFrom. Les messages privés d’approbation de Plugin Slack utilisent les approbateurs de Plugin Slack issus de allowFrom et l’acheminement par défaut du compte, et non les approbateurs d’exécution Slack. Les boutons natifs Slack conservent le type de l’identifiant d’approbation, de sorte que les identifiants plugin: peuvent traiter les approbations de Plugin sans seconde couche de repli locale à Slack.
• Les cartes natives de Google Chat conservent le repli manuel /approve dans le texte du message, mais les rappels des boutons de la carte ne transportent que des jetons d’action opaques ; l’identifiant d’approbation et la décision sont récupérés depuis l’état des demandes en attente côté serveur.
• Les approbations par emoji WhatsApp gèrent à la fois les invites d’exécution et de Plugin lorsque la famille de transfert de niveau supérieur correspondante achemine vers WhatsApp. Les invites d’origine native sont liées directement ; la remise en mode cible partagé lie les mêmes métadonnées typées d’approbation à l’accusé de réception de message WhatsApp accepté.
• Les approbations par réaction Signal gèrent à la fois les invites d’exécution et de Plugin uniquement lorsque la famille de transfert de niveau supérieur correspondante est activée et achemine vers Signal. Les approbations d’exécution Signal directes dans la même conversation peuvent supprimer le repli local /approve sans approbateurs explicites ; la résolution par réaction Signal nécessite toujours des approbateurs Signal explicites provenant de channels.signal.allowFrom ou defaultTo.
• L’acheminement natif Matrix par message privé ou canal et les raccourcis par réaction gèrent les approbations d’exécution et de Plugin ; l’autorisation des Plugins provient toujours de channels.matrix.dm.allowFrom. Les invites natives Matrix incluent le contenu d’événement personnalisé com.openclaw.approval dans le premier événement d’invite afin que les clients Matrix compatibles avec OpenClaw puissent lire l’état d’approbation structuré, tandis que les clients standard conservent le repli en texte brut /approve.
• Les boutons d’approbation natifs Discord et Telegram transportent un type explicite de propriétaire d’exécution ou de Plugin dans les données de rappel privées au transport et ne traitent que ce propriétaire. Les anciens contrôles /approve dépourvus de type restent un chemin de compatibilité limité : ils essaient uniquement les types de propriétaires que l’acteur peut approuver, ne poursuivent qu’après un résultat indiquant que l’approbation est introuvable et ne déduisent jamais la propriété à partir de l’identifiant d’approbation.
• Le demandeur n’a pas besoin d’être un approbateur.
• Si aucune interface opérateur ni aucun client d’approbation configuré ne peut accepter la demande, l’invite utilise askFallback comme solution de repli.

Les commandes de groupe sensibles réservées au propriétaire, telles que /diagnostics et /export-trajectory, utilisent un acheminement privé vers le propriétaire pour les invites d’approbation et les résultats finaux. OpenClaw essaie d’abord un acheminement privé sur la même interface que celle depuis laquelle le propriétaire a exécuté la commande. Si cette interface ne dispose d’aucun acheminement privé vers le propriétaire, OpenClaw utilise à la place le premier acheminement disponible vers le propriétaire dans commands.ownerAllowFrom, de sorte qu’une commande de groupe Discord peut toujours envoyer l’approbation et le résultat dans le message privé Telegram du propriétaire lorsque Telegram est configuré comme interface privée principale. La conversation de groupe reçoit uniquement un bref accusé de réception.

Voir :

• Discord
• Telegram
• QQ bot

Applications mobiles officielles pour les opérateurs

Les applications officielles iOS et Android peuvent également examiner les approbations d’exécution en attente détenues par le Gateway lorsqu’une connexion operator.admin est utilisée, ou lorsque leur appareil operator.approvals associé a été explicitement ciblé par la demande. Elles lisent le même enregistrement durable assaini que celui utilisé par la Control UI, envoient une décision tenant compte du type et affichent le résultat canonique de la première réponse du Gateway. L’Apple Watch reproduit ces invites d’approbation par l’intermédiaire de l’iPhone associé, avec des actions d’autorisation unique et de refus. Le mode Gateway direct de la Watch ne permet pas d’examiner les approbations.

La perte d’un accusé de réception de la résolution ne rend pas le choix envoyé définitif : l’application désactive les contrôles et relit l’enregistrement. Si une autre interface a prévalu, l’application affiche cette décision enregistrée. Les invites en attente restent liées au Gateway qui les a émises ; changer de Gateway actif ne peut donc pas rediriger un ancien identifiant d’approbation.

Flux IPC macOS

OC_I18N_900004 Remarques de sécurité :

• Mode du socket Unix 0600, jeton stocké dans exec-approvals.json.
• Vérification du pair avec le même UID.
• Défi/réponse (nonce + jeton HMAC + hachage de la demande) + TTL court.

FAQ

Quand accountId et threadId sont-ils utilisés sur une cible d’approbation ?

Utilisez accountId lorsque plusieurs identités sont configurées pour le canal et que l’invite d’approbation doit être envoyée par un compte précis. Utilisez threadId lorsque la destination prend en charge les sujets ou les fils de discussion et que l’invite doit rester dans ce fil plutôt que dans la conversation de premier niveau.

Un exemple concret pour Telegram est un supergroupe d’exploitation avec des sujets de forum et deux comptes de bot Telegram. La valeur to désigne le supergroupe, accountId sélectionne le compte du bot et threadId sélectionne le sujet du forum : OC_I18N_900005 Avec cette configuration, les approbations d’exécution transférées sont publiées par le compte Telegram ops-bot dans le sujet 77 de la conversation -1001234567890. Une cible sans accountId utilise le compte par défaut du canal, et une cible sans threadId publie dans la destination de premier niveau.

Lorsque les approbations sont envoyées à une session, n’importe quel participant de cette session peut-il les approuver ?

Non. La remise dans une session détermine uniquement où l’invite apparaît. Elle n’autorise pas à elle seule chaque participant de cette conversation à approuver.

Pour le mécanisme générique /approve dans la même conversation, l’expéditeur doit déjà être autorisé à exécuter des commandes dans cette session de canal. Si le canal expose des approbateurs explicites, ceux-ci peuvent autoriser l’action /approve même s’ils ne sont pas autrement autorisés à exécuter des commandes dans cette session.

Certains canaux sont plus stricts. Les messages privés d’approbation natifs de Discord, Telegram, Matrix et Slack, ainsi que les clients d’approbation natifs similaires, utilisent leurs listes d’approbateurs résolues pour autoriser les approbations. Par exemple, une invite d’approbation dans un sujet de forum Telegram peut être visible par tous les participants du sujet, mais seuls les identifiants numériques des utilisateurs Telegram résolus à partir de channels.telegram.execApprovals.approvers ou de commands.ownerAllowFrom peuvent l’approuver ou la refuser.

Pages connexes

• Approbations d’exécution — politique centrale et flux d’approbation
• Outil d’exécution
• Mode privilégié
• Skills — comportement d’autorisation automatique reposant sur les Skills