​

Approvazioni Exec

​

Dove si applica

• gateway host → processo openclaw sulla macchina gateway
• node host → esecutore del nodo (app complementare macOS o host nodo headless)

• I chiamanti autenticati dal Gateway sono operatori fidati per quel Gateway.
• I nodi abbinati estendono questa capacità di operatore fidato all’host del nodo.
• Le approvazioni Exec riducono il rischio di esecuzione accidentale, ma non costituiscono un confine di autenticazione per utente.
• Le esecuzioni approvate sull’host del nodo associano il contesto di esecuzione canonico: cwd canonico, argv esatto, binding env quando presente, e percorso dell’eseguibile bloccato quando applicabile.
• Per gli script shell e le invocazioni dirette di file interprete/runtime, OpenClaw prova anche ad associare un singolo operando file locale concreto. Se quel file associato cambia dopo l’approvazione ma prima dell’esecuzione, l’esecuzione viene negata invece di eseguire contenuto modificato.
• Questo binding del file è intenzionalmente best-effort, non un modello semantico completo di ogni percorso di caricamento di interpreti/runtime. Se la modalità di approvazione non riesce a identificare esattamente un file locale concreto da associare, rifiuta di creare un’esecuzione supportata da approvazione invece di fingere copertura completa.

• Il servizio host del nodo inoltra system.run alla app macOS tramite IPC locale.
• La app macOS applica le approvazioni + esegue il comando nel contesto UI.

​

Impostazioni e archiviazione

{
  "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"
        }
      ]
    }
  }
}

​

Modalità “YOLO” senza approvazione

• criterio exec richiesto nella configurazione di OpenClaw (tools.exec.*)
• criterio locale host delle approvazioni in ~/.openclaw/exec-approvals.json

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

• tools.exec.host=auto sceglie dove viene eseguito exec: sandbox quando disponibile, altrimenti gateway.
• YOLO sceglie come viene approvato l’exec host: security=full più ask=off.
• auto non trasforma il routing gateway in un override libero da una sessione in sandbox. Una richiesta per chiamata host=node è consentita da auto, e host=gateway è consentito da auto solo quando non è attivo alcun runtime sandbox. Se vuoi un valore predefinito stabile non auto, imposta tools.exec.host oppure usa /exec host=... esplicitamente.

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 cambia solo la sessione corrente.
• /elevated full è una scorciatoia break-glass che salta anche le approvazioni Exec per quella sessione.

​

Opzioni del criterio

​

Sicurezza (exec.security)

• deny: blocca tutte le richieste exec host.
• allowlist: consente solo i comandi presenti in allowlist.
• full: consente tutto (equivalente a elevated).

​

Ask (exec.ask)

• off: non mostrare mai prompt.
• on-miss: mostra il prompt solo quando non c’è corrispondenza nell’allowlist.
• always: mostra il prompt per ogni comando.
• La fiducia durevole allow-always non sopprime i prompt quando la modalità ask effettiva è always

​

Ask fallback (askFallback)

• deny: blocca.
• allowlist: consente solo se c’è corrispondenza nell’allowlist.
• full: consente.

​

Hardening eval inline dell’interprete (tools.exec.strictInlineEval)

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

• questi comandi richiedono comunque approvazione esplicita;
• allow-always non rende persistenti automaticamente nuove voci di allowlist per essi.

​

Allowlist (per agente)

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

• id UUID stabile usato per l’identità nella UI (facoltativo)
• timestamp last used
• last used command
• last resolved path

​

Auto-allow dei CLI delle Skills

• Questa è un’allowlist implicita di convenienza, separata dalle voci manuali dell’allowlist dei percorsi.
• È pensata per ambienti con operatori fidati in cui Gateway e nodo sono nello stesso confine di fiducia.
• Se richiedi una fiducia esplicita rigorosa, mantieni autoAllowSkills: false e usa solo voci manuali dell’allowlist dei percorsi.

​

Safe bins (solo stdin)

• 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 rispetto all’allowlist

• safeBins proviene dalla configurazione (tools.exec.safeBins oppure agents.list[].tools.exec.safeBins per agente).
• safeBinTrustedDirs proviene dalla configurazione (tools.exec.safeBinTrustedDirs oppure agents.list[].tools.exec.safeBinTrustedDirs per agente).
• safeBinProfiles proviene dalla configurazione (tools.exec.safeBinProfiles oppure agents.list[].tools.exec.safeBinProfiles per agente). Le chiavi di profilo per agente sovrascrivono le chiavi globali.
• le voci dell’allowlist risiedono nel file locale host ~/.openclaw/exec-approvals.json sotto agents.<id>.allowlist (oppure tramite Control UI / openclaw approvals allowlist ...).
• openclaw security audit avvisa con tools.exec.safe_bins_interpreter_unprofiled quando binari interprete/runtime compaiono in safeBins senza profili espliciti.
• openclaw doctor --fix può generare i valori mancanti safeBinProfiles.<bin> come {} (rivedili e rendili più restrittivi dopo). I binari interprete/runtime non vengono generati automaticamente.

​

Modifica dalla Control UI

​

Flusso di approvazione

• il percorso exec del nodo prepara in anticipo un unico piano canonico
• il record di approvazione memorizza quel piano e i suoi metadati di binding
• una volta approvata, la chiamata finale system.run inoltrata riusa il piano memorizzato invece di fidarsi di modifiche successive del chiamante
• se il chiamante cambia command, rawCommand, cwd, agentId oppure sessionKey dopo la creazione della richiesta di approvazione, il gateway rifiuta l’esecuzione inoltrata come mancata corrispondenza dell’approvazione

​

Comandi di interpreti/runtime

• Il contesto esatto di argv/cwd/env viene sempre associato.
• Le forme di script shell diretto e di file runtime diretto vengono associate in best-effort a uno snapshot di un singolo file locale concreto.
• Le forme wrapper comuni dei package manager che si risolvono comunque in un solo file locale diretto (per esempio pnpm exec, pnpm node, npm exec, npx) vengono spacchettate prima del binding.
• Se OpenClaw non riesce a identificare esattamente un singolo file locale concreto per un comando interprete/runtime (per esempio script di package, forme eval, catene di loader specifiche del runtime o forme ambigue multi-file), l’esecuzione supportata da approvazione viene negata invece di dichiarare una copertura semantica che non possiede.
• Per questi flussi di lavoro, preferisci la sandbox, un confine host separato oppure un flusso esplicito con allowlist/full fidato in cui l’operatore accetta la semantica più ampia del runtime.

​

Comportamento di recapito del follow-up

• Se esiste una destinazione esterna valida per il recapito (canale recapitabile più destinazione to), il recapito del follow-up usa quel canale.
• Nei flussi solo webchat o solo sessione interna senza destinazione esterna, il recapito del follow-up resta solo sessione (deliver: false).
• Se un chiamante richiede esplicitamente un recapito esterno rigoroso senza un canale esterno risolvibile, la richiesta fallisce con INVALID_REQUEST.
• Se bestEffortDeliver è abilitato e non è possibile risolvere alcun canale esterno, il recapito viene declassato a solo sessione invece di fallire.

• comando + argomenti
• cwd
• id agente
• percorso dell’eseguibile risolto
• host + metadati del criterio

• Allow once → esegui ora
• Always allow → aggiungi all’allowlist + esegui
• Deny → blocca

​

Inoltro delle approvazioni ai canali di chat

​

Inoltro delle approvazioni dei plugin

​

Approvazioni nella stessa chat su qualsiasi canale

​

Recapito nativo delle approvazioni

• il criterio exec host continua a decidere se è richiesta un’approvazione exec
• approvals.exec controlla l’inoltro dei prompt di approvazione verso altre destinazioni chat
• channels.<channel>.execApprovals controlla se quel canale agisce come client nativo di approvazione

• il canale supporta il recapito nativo delle approvazioni
• gli approvatori possono essere risolti da execApprovals.approvers esplicito oppure dalle sorgenti di fallback documentate per quel canale
• channels.<channel>.execApprovals.enabled non è impostato oppure è "auto"

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

• Slack, Matrix, Microsoft Teams e chat recapitabili simili usano il normale modello di autenticazione del canale per /approve nella stessa chat
• quando un client nativo di approvazione si abilita automaticamente, la destinazione nativa predefinita è rappresentata dai DM degli approvatori
• per Discord e Telegram, solo gli approvatori risolti possono approvare o negare
• gli approvatori Discord possono essere espliciti (execApprovals.approvers) o dedotti da commands.ownerAllowFrom
• gli approvatori Telegram possono essere espliciti (execApprovals.approvers) o dedotti dalla configurazione owner esistente (allowFrom, più defaultTo del messaggio diretto dove supportato)
• gli approvatori Slack possono essere espliciti (execApprovals.approvers) o dedotti da commands.ownerAllowFrom
• i pulsanti nativi Slack preservano il tipo di id dell’approvazione, quindi gli id plugin: possono risolvere le approvazioni plugin senza un secondo livello di fallback locale a Slack
• l’instradamento DM/canale nativo di Matrix è solo exec; le approvazioni plugin di Matrix restano sul flusso condiviso /approve nella stessa chat e sui percorsi facoltativi di inoltro approvals.plugin
• il richiedente non deve necessariamente essere un approvatore
• la chat di origine può approvare direttamente con /approve quando quella chat supporta già comandi e risposte
• i pulsanti nativi di approvazione Discord instradano in base al tipo di id dell’approvazione: gli id plugin: vanno direttamente alle approvazioni plugin, tutto il resto va alle approvazioni exec
• i pulsanti nativi di approvazione Telegram seguono lo stesso fallback limitato da exec a plugin di /approve
• quando target nativo abilita il recapito alla chat di origine, i prompt di approvazione includono il testo del comando
• le approvazioni exec in sospeso scadono dopo 30 minuti per impostazione predefinita
• se nessuna UI operatore o client di approvazione configurato può accettare la richiesta, il prompt usa askFallback

• Discord
• Telegram

​

Flusso IPC su macOS

• Modalità Unix socket 0600, token memorizzato in exec-approvals.json.
• Controllo peer con stesso UID.
• Challenge/response (nonce + token HMAC + hash della richiesta) + TTL breve.

​

Eventi di sistema

• Exec running (solo se il comando supera la soglia di notifica di esecuzione)
• Exec finished
• Exec denied

​

Comportamento delle approvazioni negate

​

Implicazioni

• full è potente; preferisci le allowlist quando possibile.
• ask ti mantiene coinvolto consentendo comunque approvazioni rapide.
• Le allowlist per agente impediscono che le approvazioni di un agente si estendano ad altri.
• Le approvazioni si applicano solo alle richieste exec host provenienti da mittenti autorizzati. I mittenti non autorizzati non possono emettere /exec.
• /exec security=full è una comodità a livello di sessione per operatori autorizzati e per progettazione salta le approvazioni. Per bloccare in modo rigido l’exec host, imposta la sicurezza delle approvazioni su deny oppure nega lo strumento exec tramite il criterio degli strumenti.

• Strumento Exec
• Modalità elevated
• Skills

​

Correlati

• Exec — strumento di esecuzione di comandi shell
• Sandboxing — modalità sandbox e accesso al workspace
• Sicurezza — modello di sicurezza e hardening
• Sandbox vs Tool Policy vs Elevated — quando usare ciascuno