​

Approbations d’exécution

​

Où cela s’applique

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

• 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 de nœud.
• Les approbations d’exécution réduisent le risque d’exécution accidentelle, mais ne constituent pas une frontière d’authentification par utilisateur.
• Les exécutions approuvées sur l’hôte de nœud lient le contexte d’exécution canonique : cwd canonique, argv exact, liaison d’environnement lorsqu’elle est présente, et chemin d’exécutable épinglé lorsque applicable.
• Pour les scripts shell et les invocations directes de fichier via 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 dérivé.
• Cette liaison de fichier est volontairement au mieux, et non un modèle sémantique complet de chaque chemin de chargement d’interpréteur/runtime. Si le mode d’approbation ne peut pas identifier exactement un fichier local concret à lier, il refuse de créer une exécution adossée à une approbation au lieu de prétendre à une couverture complète.

• service d’hôte de nœud transfère system.run à la app macOS via IPC local.
• app macOS applique les approbations + exécute la commande dans le contexte UI.

​

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

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

• tools.exec.security: full sur gateway/node
• tools.exec.ask: off
• hôte askFallback: full

• tools.exec.host=auto choisit où l’exécution s’effectue : dans le sandbox s’il est disponible, sinon sur la gateway.
• YOLO choisit comment l’exécution hôte est approuvée : security=full plus ask=off.
• En mode YOLO, OpenClaw n’ajoute pas de barrière distincte d’approbation heuristique contre l’obfuscation de commandes ni de couche de rejet préalable de script par-dessus la politique configurée d’exécution hôte.
• auto ne transforme pas le routage gateway en substitution libre depuis une session sandboxée. Une demande 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 auto, 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 exec-policy preset yolo

• tools.exec.host/security/ask local
• les valeurs par défaut de ~/.openclaw/exec-approvals.json local

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

• openclaw exec-policy ne synchronise pas les approbations de nœud
• openclaw exec-policy set --host node est rejeté
• les approbations d’exécution sur nœud sont récupérées depuis le nœud à l’exécution ; les mises à jour ciblant le nœud doivent donc utiliser openclaw approvals --node ...

• /exec security=full ask=off ne modifie que la session actuelle.
• /elevated full est un raccourci de type break-glass qui ignore aussi les approbations d’exécution pour cette session.

​

Paramètres de politique

​

Sécurité (exec.security)

• deny : bloque toutes les demandes d’exécution hôte.
• allowlist : autorise uniquement les commandes présentes dans la liste d’autorisation.
• full : autorise tout (équivalent à elevated).

​

Ask (exec.ask)

• off : ne jamais demander.
• on-miss : demander uniquement lorsqu’aucune correspondance de liste d’autorisation n’est trouvée.
• always : demander pour chaque commande.
• la confiance durable allow-always ne supprime pas les invites lorsque le mode ask effectif est always

​

Repli Ask (askFallback)

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

​

Renforcement de l’évaluation 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 persiste 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’UI (facultatif)
• last used horodatage
• last used command
• last resolved path

​

Auto-allow skill CLIs

• 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 aux environnements d’opérateurs de confiance où la Gateway et le nœud partagent la même frontière de confiance.
• Si vous avez besoin d’une confiance explicite stricte, conservez 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 liste d’autorisation

• safeBins provient de la configuration (tools.exec.safeBins ou agents.list[].tools.exec.safeBins par agent).
• safeBinTrustedDirs provient de la configuration (tools.exec.safeBinTrustedDirs ou agents.list[].tools.exec.safeBinTrustedDirs par agent).
• safeBinProfiles provient de la configuration (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 résident dans ~/.openclaw/exec-approvals.json local à l’hôte sous agents.<id>.allowlist (ou via Control UI / 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 personnalisées manquantes safeBinProfiles.<bin> sous la forme {} (à examiner et resserrer ensuite). Les binaires d’interpréteur/runtime ne sont pas générés automatiquement.

​

Édition dans Control UI

​

Flux d’approbation

• le chemin d’exécution node prépare un plan canonique en amont
• l’enregistrement d’approbation stocke ce plan et ses métadonnées de liaison
• une fois approuvée, l’appel final transféré system.run 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 demande d’approbation, la gateway rejette l’exécution transférée comme incompatibilité d’approbation

​

Commandes d’interpréteur/runtime

• Le contexte exact argv/cwd/env est toujours lié.
• Les scripts shell directs et les formes directes de fichier runtime sont liés 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 fichier local direct unique (par exemple pnpm exec, pnpm node, npm exec, npx) sont déballé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 package, formes eval, chaînes de chargement spécifiques au runtime, ou formes multi-fichiers ambiguës), l’exécution adossée à une approbation est refusée au lieu de prétendre à une couverture sémantique qu’elle ne possède pas.
• Pour ces workflows, préférez le sandboxing, une frontière hôte distincte, ou un workflow explicite allowlist/full de confiance où l’opérateur accepte la sémantique plus large du runtime.

​

Comportement de livraison du 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 demande échoue avec INVALID_REQUEST.
• Si bestEffortDeliver est activé et qu’aucun canal externe ne peut être résolu, la livraison est rétrogradée à la session uniquement au lieu d’échouer.

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

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

​

Transfert des approbations vers les canaux de chat

​

Transfert des approbations de Plugin

​

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

​

Livraison native des approbations

• la politique d’exécution hôte décide toujours si une approbation d’exécution 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 secours documentées de 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 chats livrables similaires 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 le DM des approbateurs
• pour Discord et Telegram, seuls les approbateurs résolus peuvent autoriser 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 lorsqu’il est 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’identifiant d’approbation, de sorte que les identifiants plugin: peuvent résoudre des approbations de Plugin sans seconde couche locale de secours propre à Slack
• le routage DM/canal natif Matrix et les raccourcis de réaction gèrent à la fois les approbations d’exécution et de Plugin ; l’autorisation de Plugin provient toujours de channels.matrix.dm.allowFrom
• 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 les commandes et les réponses
• les boutons natifs d’approbation Discord routent selon le type d’identifiant d’approbation : les identifiants plugin: vont directement vers les approbations de Plugin, tout le reste va vers les approbations d’exécution
• les boutons natifs d’approbation Telegram suivent le même repli borné exec-vers-plugin que /approve
• lorsque target natif active la livraison vers le chat d’origine, les invites d’approbation incluent le texte de la commande
• les approbations d’exécution en attente expirent après 30 minutes par défaut
• si aucune interface opérateur ou aucun client d’approbation configuré ne peut accepter la demande, l’invite revient à askFallback

• Discord
• Telegram

​

Flux IPC macOS

• Mode du socket Unix 0600, jeton stocké dans exec-approvals.json.
• Vérification de pair de même UID.
• Challenge/réponse (nonce + jeton HMAC + hachage de requête) + TTL court.

​

Événements système

• Exec running (uniquement si la commande dépasse le seuil de notification 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 garde dans la boucle tout en permettant des approbations rapides.
• Les listes d’autorisation par agent empêchent qu’une approbation d’un agent ne fuite vers un autre.
• Les approbations ne s’appliquent qu’aux demandes d’exécution 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 session pour les opérateurs autorisés et ignore les approbations par conception. Pour bloquer strictement l’exécution hôte, définissez la sécurité des approbations sur deny ou refusez l’outil exec via la politique d’outils.

• Exec tool
• Elevated mode
• 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