Lo strumento exec di OpenClaw
Una superficie shell che modifica i file, con la risoluzione dell’host tra sandbox, gateway e nodo, le cinque modalità di policy da deny a full, il revisore automatico, la valutazione inline rigorosa, la gestione del PATH e gli override per sessione
Exec è lo strumento che rende operativo un agente ed è quello che merita più attenzione. È una shell, scrive file, e dove viene eseguito è una questione di risoluzione più che una risposta fissa. Ecco i parametri disponibili, le regole di collocazione, le cinque modalità di policy con il revisore che opera all’interno di una di esse e i comandi di sessione che possono restringere, ma mai allentare.
Parametri e collocazione
- Il comando è l’unico parametro obbligatorio; una directory di lavoro, override dell’ambiente, un ritardo prima del passaggio in background, un flag per il background immediato, un timeout per chiamata in secondi, un flag di pseudo-terminale per i programmi che funzionano solo in un terminale, una modalità di richiesta, un selettore di nodo e un flag di elevazione completano i parametri, e un timeout pari a zero disattiva il timeout del processo per quella chiamata.
- Il parametro host accetta solo auto, sandbox, gateway o node e non è un selettore di nome host; auto eredita l’host configurato, compresi gli override di agente e sessione, e quando anche quello è auto si risolve nella sandbox se è attivo un runtime di sandbox e nel gateway negli altri casi, mentre una sessione che richiede una sandbox resta comunque nella sandbox.
- Mentre è attivo un runtime di sandbox, auto mantiene exec nella sandbox e rifiuta gli override per chiamata verso gateway o node, quindi per forzare l’uno o l’altro occorre impostare esplicitamente l’host configurato; l’esecuzione su un nodo richiede un nodo abbinato e connesso che supporti il comando di esecuzione, e con più nodi idonei connessi bisogna selezionare una destinazione nella configurazione o per sessione.
- L’esecuzione sull’host rifiuta gli override d’ambiente del PATH e del loader per impedire il dirottamento dei binari, normalizza un override del pager a un valore vuoto invece di passare il nome di un eseguibile, imposta una variabile marcatore così i profili della shell possono rilevare il contesto exec e, sul gateway, unisce il PATH della shell di login caricando un’istantanea di avvio acquisita che esclude le variabili che sembrano segreti.
exec è una superficie shell che modifica: i comandi possono creare, modificare o eliminare file ovunque lo consenta il file system dell’host o della sandbox selezionati.
Le cinque modalità e il revisore
La chiave mode è il parametro canonico della policy e tutto il resto deriva da essa. La modalità deny blocca exec del tutto. La modalità allowlist esegue solo i comandi presenti nell’elenco degli autorizzati o tra i safe bin e non chiede nulla. La modalità ask esegue direttamente le corrispondenze con l’elenco e invia tutto il resto a una persona. La modalità auto esegue direttamente le corrispondenze e passa i comandi idonei non coperti dall’elenco a un revisore nativo che restituisce allow, deny o ask, dove allow esegue una sola volta un comando a rischio basso o medio, deny restituisce una motivazione che l’agente deve rispettare anziché aggirare, e tre rifiuti consecutivi in una sessione fanno passare il terzo comando a una persona. La modalità full esegue senza le normali richieste della policy, e l’exec sull’host senza approvazione è il comportamento predefinito per gateway e nodo a causa dei valori predefiniti della policy dell’host, non dell’host auto. Sul gateway, i comandi devono superare i controlli di vincolo sui file modificabili prima della revisione: l’intera catena di dispatch viene vincolata al momento della revisione e ricontrollata prima dell’avvio, gli eseguibili protetti tramite il percorso reale risolto e quelli scrivibili anche tramite l’hash del contenuto, quindi un nuovo eseguibile che compare prima nel percorso di ricerca fa rifiutare l’esecuzione approvata. I wrapper di comandi shell, le assegnazioni di variabili d’ambiente e le altre catene non vincolabili saltano il revisore e seguono invece il percorso di approvazione umana una tantum.
Valutazione inline, PATH e sessioni
- La valutazione inline rigorosa è un’opzione separata da attivare esplicitamente, disattivata per impostazione predefinita: quando viene eseguita la normale valutazione dell’approvazione sull’host, richiede l’approvazione del revisore o un’approvazione esplicita per le forme riconosciute di interprete inline anche quando la policy consente full e off, copre i flag di eval degli interpreti più comuni e dei comandi che li incapsulano, e le forme di eval inline non diventano mai regole di autorizzazione durevoli.
- La gestione del PATH varia in base all’host: il gateway unisce il PATH della shell di login e antepone in modo sicuro le directory configurate subito prima dell’esecuzione; la sandbox esegue una shell di login all’interno del container, quindi il profilo può reimpostare il PATH e le voci configurate vengono anteposte dopo il caricamento del profilo; e gli host nodo ignorano del tutto gli override del PATH, quindi le voci aggiuntive vanno nell’ambiente del servizio del nodo.
- Un comando di sessione imposta i valori predefiniti di collocazione per la sessione, mentre security e ask si applicano solo al messaggio corrente; viene rispettato solo per i mittenti autorizzati, i mittenti esterni possono rendere persistenti i valori predefiniti di collocazione mentre i client interni hanno bisogno di uno scope amministrativo, e quando una sessione ha una modalità di permessi l’override per turno può solo renderla più restrittiva, mai allentarla.
Le approvazioni exec in OpenClaw sono il flusso di approvazione che queste modalità alimentano, mentre la guida avanzata alle approvazioni exec in OpenClaw descrive le regole sui safe bin e sui vincoli che stanno dietro.
Due errori comuni
Il primo è pensare che gli strumenti per i file siano la superficie di scrittura: disattivarli non rende exec di sola lettura, perché la shell scrive ovunque l’host selezionato lo consenta. Il secondo è pensare che la sandbox sia attiva: è disattivata per impostazione predefinita, quindi un host auto implicito si risolve nel gateway, mentre una richiesta esplicita di sandbox fallisce bloccando l’esecuzione (fail closed) invece di essere eseguita in silenzio sull’host. Per lo stesso motivo vale la pena conoscere il sottostrumento di patch strutturate, dato che consentire lo strumento write lo consente implicitamente, mentre negare write non lo nega. Disattivare exec del tutto è una decisione di policy degli strumenti, e al di fuori di una sessione con accesso completo si applicano comunque le soglie minime di approvazione dell’host. La guida alla sandbox di OpenClaw spiega l’isolamento, mentre le skill di OpenClaw sono i file di istruzioni che di solito guidano questi comandi.
Su Diali
Su Diali ogni assistente viene eseguito nel proprio motore, con la configurazione generata dalla dashboard e sostituita a ogni rilascio, quindi la shell a cui arriva un agente è il motore di quel cliente e nient’altro. OpenClaw ospitato su Diali descrive l’assistente ospitato, mentre la pagina sulla sicurezza di Diali illustra il confine che lo circonda.
- Disattivare gli strumenti per i file non rende la shell di sola lettura.
- La sandbox è disattivata per impostazione predefinita; auto allora significa il gateway.
- Gli override per turno rendono la policy più restrittiva, mai più permissiva.
Basta leggere, creane uno tuo
Configura un agente, scegli un canale e fallo lavorare dentro l’app che tieni già aperta.
