​

Approbations d’exec

​

Où cela s’applique

• hôte gateway → processus openclaw sur la machine gateway
• hôte node → exécuteur de nœud (application compagnon macOS ou hôte de nœud sans interface)

• Les appelants authentifiés auprès de la gateway sont des opérateurs de confiance pour cette Gateway.
• Les nœuds appairés étendent cette capacité d’opérateur de confiance à l’hôte du nœud.
• Les approbations d’exec réduisent le risque d’exécution accidentelle, mais ne constituent pas une limite d’authentification par utilisateur.
• Les exécutions approuvées sur l’hôte du nœud lient un contexte d’exécution canonique : cwd canonique, argv exact, liaison d’environnement si présente, et chemin d’exécutable épinglé si applicable.
• Pour les scripts shell et les invocations directes de fichiers d’interpréteur/runtime, OpenClaw essaie aussi de lier un opérande de fichier local concret. Si ce fichier lié change après l’approbation mais avant l’exécution, l’exécution est refusée au lieu d’exécuter un contenu modifié.
• Cette liaison de fichier est volontairement faite au mieux, et non comme un modèle sémantique complet de tous les chemins de chargement d’interpréteur/runtime. Si le mode d’approbation ne peut pas identifier exactement un fichier local concret à lier, il refuse de produire une exécution adossée à une approbation au lieu de prétendre à une couverture complète.

• Le service d’hôte de nœud transmet system.run à l’application macOS via IPC local.
• L’application macOS applique les approbations + exécute la commande dans le contexte de l’interface.

​

Paramètres et stockage

{
  "version": 1,
  "socket": {
    "path": "~/.openclaw/exec-approvals.sock",
    "token": "base64url-token"
  },
  "defaults": {
    "security": "deny",
    "ask": "on-miss",
    "askFallback": "deny",
    "autoAllowSkills": false
  },
  "agents": {
    "main": {
      "security": "allowlist",
      "ask": "on-miss",
      "askFallback": "deny",
      "autoAllowSkills": true,
      "allowlist": [
        {
          "id": "B0C8C0B3-2C2D-4F8A-9A3C-5A4B3C2D1E0F",
          "pattern": "~/Projects/**/bin/rg",
          "lastUsedAt": 1737150000000,
          "lastUsedCommand": "rg -n TODO",
          "lastResolvedPath": "/Users/user/Projects/.../bin/rg"
        }
      ]
    }
  }
}

​

Mode “YOLO” sans approbation

• la politique exec demandée dans la config OpenClaw (tools.exec.*)
• la politique d’approbations locale à l’hôte dans ~/.openclaw/exec-approvals.json

• tools.exec.security: full sur gateway/node
• tools.exec.ask: off
• host askFallback: full

• tools.exec.host=auto choisit où exec s’exécute : en sandbox si disponible, sinon sur la gateway.
• YOLO choisit comment l’exec sur l’hôte est approuvé : security=full plus ask=off.
• auto ne transforme pas le routage gateway en dérogation gratuite depuis une session sandboxée. Une requête par appel host=node est autorisée depuis auto, et host=gateway n’est autorisé depuis auto que lorsqu’aucun runtime sandbox n’est actif. Si vous voulez une valeur par défaut stable non automatique, définissez tools.exec.host ou utilisez /exec host=... explicitement.

openclaw config set tools.exec.host gateway
openclaw config set tools.exec.security full
openclaw config set tools.exec.ask off
openclaw gateway restart

openclaw approvals set --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF

openclaw approvals set --node <id|name|ip> --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF

• /exec security=full ask=off modifie uniquement la session en cours.
• /elevated full est un raccourci “break-glass” qui ignore aussi les approbations d’exec pour cette session.

​

Réglages de politique

​

Sécurité (exec.security)

• deny : bloque toutes les requêtes d’exec sur l’hôte.
• allowlist : n’autorise que les commandes présentes dans la liste d’autorisation.
• full : autorise tout (équivalent à elevated).

​

Ask (exec.ask)

• off : ne jamais afficher d’invite.
• on-miss : afficher une invite uniquement quand la liste d’autorisation ne correspond pas.
• always : afficher une invite pour chaque commande.
• la confiance durable allow-always ne supprime pas les invites lorsque le mode ask effectif est always

​

Solution de repli ask (askFallback)

• deny : bloquer.
• allowlist : autoriser uniquement si la liste d’autorisation correspond.
• full : autoriser.

​

Renforcement d’eval inline d’interpréteur (tools.exec.strictInlineEval)

• python -c
• node -e, node --eval, node -p
• ruby -e
• perl -e, perl -E
• php -r
• lua -e
• osascript -e

• ces commandes nécessitent toujours une approbation explicite ;
• allow-always ne conserve pas automatiquement de nouvelles entrées de liste d’autorisation pour elles.

​

Liste d’autorisation (par agent)

• ~/Projects/**/bin/peekaboo
• ~/.local/bin/*
• /opt/homebrew/bin/rg

• id UUID stable utilisé pour l’identité dans l’interface (facultatif)
• dernière utilisation horodatage
• dernière commande utilisée
• dernier chemin résolu

​

Autoriser automatiquement les CLI de Skills

• Il s’agit d’une liste d’autorisation implicite de commodité, distincte des entrées manuelles de liste d’autorisation par chemin.
• Elle est destinée à des environnements d’opérateur de confiance où la Gateway et le nœud se trouvent dans la même limite de confiance.
• Si vous exigez une confiance explicite stricte, gardez autoAllowSkills: false et utilisez uniquement des entrées manuelles de liste d’autorisation par chemin.

​

Safe bins (stdin only)

• 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
• wc : --files0-from

​

Safe bins versus allowlist

• safeBins vient de la config (tools.exec.safeBins ou agents.list[].tools.exec.safeBins par agent).
• safeBinTrustedDirs vient de la config (tools.exec.safeBinTrustedDirs ou agents.list[].tools.exec.safeBinTrustedDirs par agent).
• safeBinProfiles vient de la config (tools.exec.safeBinProfiles ou agents.list[].tools.exec.safeBinProfiles par agent). Les clés de profil par agent remplacent les clés globales.
• les entrées de liste d’autorisation vivent dans le fichier local à l’hôte ~/.openclaw/exec-approvals.json sous agents.<id>.allowlist (ou via l’interface Control / openclaw approvals allowlist ...).
• openclaw security audit avertit avec tools.exec.safe_bins_interpreter_unprofiled lorsque des binaires d’interpréteur/runtime apparaissent dans safeBins sans profils explicites.
• openclaw doctor --fix peut générer les entrées manquantes safeBinProfiles.<bin> sous la forme {} (revoyez-les et resserrez-les ensuite). Les binaires d’interpréteur/runtime ne sont pas générés automatiquement.

​

Modification dans l’interface Control

​

Flux d’approbation

• le chemin d’exec du nœud prépare un plan canonique unique en amont
• l’enregistrement d’approbation stocke ce plan et ses métadonnées de liaison
• une fois approuvée, l’appel system.run final transmis réutilise le plan stocké au lieu de faire confiance à des modifications ultérieures de l’appelant
• si l’appelant modifie command, rawCommand, cwd, agentId, ou sessionKey après la création de la requête d’approbation, la gateway refuse l’exécution transmise pour cause d’incompatibilité d’approbation

​

Commandes d’interpréteur/runtime

• Le contexte exact argv/cwd/env est toujours lié.
• Les formes directes de scripts shell et de fichiers runtime sont liées au mieux à un instantané concret d’un fichier local.
• Les formes courantes de wrapper de gestionnaire de paquets qui se résolvent quand même en un seul fichier local direct (par exemple pnpm exec, pnpm node, npm exec, npx) sont déroulées avant la liaison.
• Si OpenClaw ne peut pas identifier exactement un fichier local concret pour une commande d’interpréteur/runtime (par exemple scripts de paquet, formes eval, chaînes de chargement spécifiques au runtime, ou formes ambiguës à plusieurs fichiers), l’exécution adossée à une approbation est refusée au lieu de prétendre à une couverture sémantique qu’elle n’a pas.
• Pour ces workflows, préférez le sandboxing, une limite d’hôte séparée, ou un workflow explicite trusted allowlist/full dans lequel l’opérateur accepte la sémantique plus large du runtime.

​

Comportement de livraison de suivi

• Si une cible de livraison externe valide existe (canal livrable plus cible to), la livraison de suivi utilise ce canal.
• Dans les flux webchat-only ou de session interne sans cible externe, la livraison de suivi reste limitée à la session (deliver: false).
• Si un appelant demande explicitement une livraison externe stricte sans canal externe résoluble, 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 session seule au lieu d’échouer.

• commande + arguments
• cwd
• id d’agent
• chemin résolu de l’exécutable
• métadonnées d’hôte + de politique

• Allow once → exécuter maintenant
• Always allow → ajouter à la liste d’autorisation + exécuter
• Deny → bloquer

​

Transmission des approbations aux canaux de chat

​

Transmission des approbations de plugin

​

Approbations dans le même chat sur n’importe quel canal

​

Livraison native des approbations

• la politique d’exec sur l’hôte décide toujours si une approbation d’exec est requise
• approvals.exec contrôle le transfert des invites d’approbation vers d’autres destinations de chat
• channels.<channel>.execApprovals contrôle si ce canal agit comme client natif d’approbation

• le canal prend en charge la livraison native des approbations
• les approbateurs peuvent être résolus à partir de execApprovals.approvers explicites ou des sources de repli documentées pour ce canal
• channels.<channel>.execApprovals.enabled n’est pas défini ou vaut "auto"

• Discord : channels.discord.execApprovals.*
• Slack : channels.slack.execApprovals.*
• Telegram : channels.telegram.execApprovals.*

• Slack, Matrix, Microsoft Teams, et autres chats livrables utilisent le modèle d’authentification normal du canal pour /approve dans le même chat
• lorsqu’un client natif d’approbation s’active automatiquement, la cible de livraison native par défaut est les DM des approbateurs
• pour Discord et Telegram, seuls les approbateurs résolus peuvent approuver ou refuser
• les approbateurs Discord peuvent être explicites (execApprovals.approvers) ou déduits de commands.ownerAllowFrom
• les approbateurs Telegram peuvent être explicites (execApprovals.approvers) ou déduits de la configuration propriétaire existante (allowFrom, plus defaultTo en message direct si pris en charge)
• les approbateurs Slack peuvent être explicites (execApprovals.approvers) ou déduits de commands.ownerAllowFrom
• les boutons natifs Slack préservent le type d’id d’approbation, de sorte que les ids plugin: peuvent résoudre les approbations de plugin sans seconde couche locale de repli propre à Slack
• le routage DM/canal natif de Matrix est réservé à exec ; les approbations de plugin Matrix restent sur le flux partagé /approve dans le même chat et les chemins facultatifs de transmission approvals.plugin
• le demandeur n’a pas besoin d’être un approbateur
• le chat d’origine peut approuver directement avec /approve lorsque ce chat prend déjà en charge commandes et réponses
• les boutons natifs d’approbation Discord routent selon le type d’id d’approbation : les ids plugin: vont directement vers les approbations de plugin, tout le reste va vers les approbations d’exec
• les boutons natifs d’approbation Telegram suivent le même mécanisme borné de repli exec-vers-plugin que /approve
• lorsque target natif active la livraison dans le chat d’origine, les invites d’approbation incluent le texte de la commande
• les approbations d’exec en attente expirent au bout de 30 minutes par défaut
• si aucune interface opérateur ou aucun client d’approbation configuré ne peut accepter la requête, l’invite se replie sur askFallback

• Discord
• Telegram

​

Flux IPC macOS

• Socket Unix en mode 0600, token stocké dans exec-approvals.json.
• Vérification du pair ayant le même UID.
• Challenge/réponse (nonce + token HMAC + hachage de requête) + TTL court.

​

Événements système

• Exec running (uniquement si la commande dépasse le seuil d’avis d’exécution)
• Exec finished
• Exec denied

​

Comportement en cas d’approbation refusée

​

Implications

• full est puissant ; préférez les listes d’autorisation lorsque c’est possible.
• ask vous maintient dans la boucle tout en permettant des approbations rapides.
• Les listes d’autorisation par agent empêchent les approbations d’un agent de fuiter vers d’autres.
• Les approbations ne s’appliquent qu’aux requêtes d’exec sur l’hôte provenant d’expéditeurs autorisés. Les expéditeurs non autorisés ne peuvent pas émettre /exec.
• /exec security=full est une commodité au niveau de la session pour les opérateurs autorisés et ignore les approbations par conception. Pour bloquer strictement l’exec sur l’hôte, définissez la sécurité des approbations sur deny ou refusez l’outil exec via la politique d’outils.

• Outil Exec
• Mode elevated
• Skills

​

Liens connexes

• Exec — outil d’exécution de commandes shell
• Sandboxing — modes sandbox et accès à l’espace de travail
• Security — modèle de sécurité et durcissement
• Sandbox vs Tool Policy vs Elevated — quand utiliser chacun