​

Approvazioni exec

​

Dove si applica

• host gateway → processo openclaw sulla macchina gateway
• host nodo → runner del nodo (app companion macOS o host nodo headless)

• I chiamanti autenticati dal Gateway sono operatori attendibili per quel Gateway.
• I nodi accoppiati estendono questa capacità di operatore attendibile all’host del nodo.
• Le approvazioni exec riducono il rischio di esecuzione accidentale, ma non sono un confine di autenticazione per utente.
• Le esecuzioni approvate sull’host del nodo vincolano il contesto di esecuzione canonico: cwd canonico, argv esatto, binding di env quando presente e percorso dell’eseguibile fissato quando applicabile.
• Per script shell e invocazioni dirette di file tramite interprete/runtime, OpenClaw cerca anche di vincolare un unico operando file locale concreto. Se quel file vincolato 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 unico file locale concreto da vincolare, rifiuta di emettere un’esecuzione supportata da approvazione invece di fingere una copertura completa.

• servizio host del nodo inoltra system.run alla app macOS tramite IPC locale.
• 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 delle approvazioni host 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: nella sandbox quando disponibile, altrimenti sul gateway.
• YOLO sceglie come viene approvato l’exec host: security=full più ask=off.
• In modalità YOLO, OpenClaw non aggiunge un controllo di approvazione separato basato su euristiche di offuscamento dei comandi sopra il criterio exec host configurato.
• auto non rende il routing gateway una sostituzione libera da una sessione sandboxed. 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 o 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 exec-policy preset yolo

• tools.exec.host/security/ask locali
• valori predefiniti locali di ~/.openclaw/exec-approvals.json

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

• openclaw exec-policy non sincronizza le approvazioni del nodo
• openclaw exec-policy set --host node viene rifiutato
• le approvazioni exec del nodo vengono recuperate dal nodo in fase di esecuzione, quindi gli aggiornamenti destinati al nodo devono usare openclaw approvals --node ...

• /exec security=full ask=off modifica solo la sessione corrente.
• /elevated full è una scorciatoia di emergenza che salta anche le approvazioni exec per quella sessione.

​

Manopole del criterio

​

Security (exec.security)

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

​

Ask (exec.ask)

• off: non richiedere mai conferma.
• on-miss: richiedi conferma solo quando l’allowlist non corrisponde.
• always: richiedi conferma per ogni comando.
• la fiducia durevole allow-always non sopprime i prompt quando la modalità ask effettiva è always

​

Ask fallback (askFallback)

• deny: blocca.
• allowlist: consenti solo se l’allowlist corrisponde.
• full: consenti.

​

Hardening dell’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à UI (facoltativo)
• ultimo utilizzo timestamp
• ultimo comando usato
• ultimo percorso risolto

​

Auto-consenti le CLI delle skill

• Questa è un’allowlist implicita di comodità, separata dalle voci manuali di allowlist per percorso.
• È pensata per ambienti con operatori attendibili in cui Gateway e nodo si trovano nello stesso confine di fiducia.
• Se richiedi una fiducia esplicita rigorosa, mantieni autoAllowSkills: false e usa solo voci manuali di allowlist per percorso.

​

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

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

​

Modifica nella 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 approvato, la chiamata finale inoltrata system.run riutilizza il piano memorizzato invece di fidarsi di modifiche successive del chiamante
• se il chiamante modifica command, rawCommand, cwd, agentId o sessionKey dopo che la richiesta di approvazione è stata creata, il gateway rifiuta l’esecuzione inoltrata come mancata corrispondenza dell’approvazione

​

Comandi di interprete/runtime

• Il contesto esatto di argv/cwd/env è sempre vincolato.
• Le forme dirette di script shell e di file runtime diretto vengono vincolate in best-effort a un unico snapshot di file locale concreto.
• Le comuni forme wrapper di package-manager che si risolvono comunque in un unico file locale diretto (ad esempio pnpm exec, pnpm node, npm exec, npx) vengono spacchettate prima del binding.
• Se OpenClaw non riesce a identificare esattamente un unico file locale concreto per un comando di interprete/runtime (ad 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 in realtà non ha.
• Per questi flussi di lavoro, preferisci la sandbox, un confine host separato o un flusso esplicito allowlist/full attendibile in cui l’operatore accetta la semantica più ampia del runtime.

​

Comportamento di consegna del followup

• Se esiste una destinazione di consegna esterna valida (canale consegnabile più target to), la consegna del followup usa quel canale.
• Nei flussi solo webchat o solo sessione interna senza destinazione esterna, la consegna del followup resta solo di sessione (deliver: false).
• Se un chiamante richiede esplicitamente una consegna esterna rigorosa senza alcun canale esterno risolvibile, la richiesta fallisce con INVALID_REQUEST.
• Se bestEffortDeliver è abilitato e non può essere risolto alcun canale esterno, la consegna viene declassata 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 chat

​

Inoltro delle approvazioni plugin

​

Approvazioni nella stessa chat su qualsiasi canale

​

Consegna nativa 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 di approvazione nativo

• il canale supporta la consegna di approvazioni native
• gli approvatori possono essere risolti da execApprovals.approvers esplicito oppure dalle origini di fallback documentate di 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 consegnabili simili usano il normale modello di autenticazione del canale per /approve nella stessa chat
• quando un client di approvazione nativo si abilita automaticamente, la destinazione nativa predefinita di consegna sono i 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 di Slack preservano il tipo dell’ID di approvazione, quindi gli ID plugin: possono risolvere le approvazioni plugin senza un secondo livello di fallback locale a Slack
• l’instradamento nativo DM/canale di Matrix e le scorciatoie tramite reaction gestiscono sia le approvazioni exec sia quelle plugin; l’autorizzazione plugin continua però a provenire da channels.matrix.dm.allowFrom
• chi effettua la richiesta non deve 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 dell’ID di 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 exec-to-plugin di /approve
• quando target nativo abilita la consegna alla chat di origine, i prompt di approvazione includono il testo del comando
• le approvazioni exec in attesa scadono dopo 30 minuti per impostazione predefinita
• se nessuna UI operatore o client di approvazione configurato può accettare la richiesta, il prompt ricorre a askFallback

• Discord
• Telegram

​

Flusso IPC macOS

• Modalità del socket Unix 0600, token archiviato in exec-approvals.json.
• Controllo del 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 dell’avviso di esecuzione)
• Exec finished
• Exec denied

​

Comportamento delle approvazioni negate

​

Implicazioni

• full è potente; preferisci le allowlist quando possibile.
• ask ti mantiene nel circuito pur consentendo approvazioni rapide.
• Le allowlist per-agente impediscono che le approvazioni di un agente si propaghino ad altri.
• Le approvazioni si applicano solo alle richieste di 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 rigidamente l’exec host, imposta la security delle approvazioni su deny o nega lo strumento exec tramite il criterio degli strumenti.

• Exec tool
• Elevated mode
• Skills

​

Correlati

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