Attivare OpenClaw da Gmail

Vuoi che l’assistente reagisca quando arriva un’email: una nuova fattura, una richiesta di supporto, un avviso di deploy fallito. Il collegamento ovvio, cioè puntare Gmail sull’agente con cui già chatti, dà a qualsiasi sconosciuto che conosca il tuo indirizzo un turno su un agente che ha in mano la tua shell, i tuoi file e il tuo browser. Il percorso Gmail di OpenClaw esiste per evitarlo, ed è una catena di componenti più che un interruttore.

Come un messaggio Gmail arriva a un agente

• Il trasporto è Google Pub/Sub. Un watch di Gmail su un’etichetta pubblica gli eventi della casella su un topic, Pub/Sub li invia con push al processo gog gmail watch serve, e quel watcher inoltra i dati dell’email all’hook HTTP del Gateway. Non carica mai un handler interno HOOK.md: questo è l’hook esterno in entrata, non il sistema di eventi interno al processo.
• I prerequisiti sono precisi: la CLI gcloud, gog autorizzato per l’account Gmail monitorato, gli hook attivati in OpenClaw, un endpoint push HTTPS che Pub/Sub riesca davvero a raggiungere (Tailscale Funnel nella configurazione consigliata) e un backend sandbox funzionante, di cui devi compilare l’immagine prima della prima esecuzione se resti sul backend Docker predefinito.
• Il Gateway avvia e rinnova da solo il watcher una volta che gli hook sono attivi e un account Gmail è impostato, con una variabile d’ambiente per disattivare questo comportamento. Eseguine esattamente uno: un secondo processo serve o un comando run manuale sullo stesso listener provoca un conflitto di bind, e un listener avviato non prova che il watch sia stato registrato.
• Un batch inviato via push diventa un’esecuzione dell’agente per email, perché il mapping si espande sull’array dei messaggi, con un limite di 200 elementi. I percorsi Gmail hanno un limite più ampio per il corpo della richiesta, derivato dal limite di byte per messaggio e con un tetto di 32 MiB, e una pagina di cronologia upstream conta i record della cronologia, non le email, quindi un arretrato può comunque raggiungere i limiti.

La sessione per messaggio del preset Gmail integrato separa il contesto della conversazione; non limita gli strumenti né lo spazio di lavoro dell’agente di destinazione.

Le sessioni per messaggio non sono un confine di permessi

Il preset dà a ogni messaggio la propria chiave di sessione, così la seconda email non può leggere la conversazione della prima. È isolamento del contesto, e non è altro. Se nessun mapping imposta un ID agente, il preset si risolve sul tuo agente predefinito, il che significa che l’email di uno sconosciuto viene riassunta dall’agente che possiede il tuo spazio di lavoro e i tuoi strumenti. Un mapping personalizzato che corrisponde al percorso gmail viene eseguito prima del preset, ed è lì che indichi il lettore, mentre l’elenco degli ID agente consentiti dell’hook impedisce a quell’endpoint di selezionare qualsiasi altro agente. Instradare Gmail verso un agente più capace è consentito, ma la documentazione ti chiede di trattarlo come una decisione di sicurezza: wrapping attivo, esecuzione in sandbox, nessun permesso oltre quanto richiesto dal flusso di lavoro.

L’agente mail_reader

• Il lettore è una seconda voce dell’elenco degli agenti, con un proprio spazio di lavoro e un proprio modello, e una sandbox impostata sulla modalità all, con scope session e nessun accesso allo spazio di lavoro. Ogni email ottiene quindi una sandbox nuova che non può raggiungere lo spazio di lavoro dell’agente host, e l’esecuzione è usa e getta per costruzione.
• La sua policy degli strumenti è il profilo minimal con un solo strumento consentito, session_status, più un elenco deny esplicito che copre i gruppi filesystem, runtime e web e gli strumenti browser, cron, gateway e nodes. Quell’elenco degli strumenti consentiti per agente è un vincolo assoluto, quindi un’aggiunta globale in also-allow non può arrivare fino al lettore, e i deny espliciti rendono verificabile il confine voluto.
• Aggiungere il lettore trasforma l’elenco in una flotta esplicita, quindi ogni canale che il tuo agente principale possiede ancora ha bisogno di un proprio binding, uno per canale, perché non esiste un carattere jolly tra canali. Elencare gli agenti con i loro binding prima di riavviare è il controllo che individua un canale senza proprietario, e la consegna è disattivata, quindi i completamenti vengono registrati nei log anziché annunciati.

Una regola coglie molti di sorpresa: le policy degli strumenti possono solo restringersi man mano che si combinano i livelli globale, provider, agente e sandbox, quindi l’elenco degli strumenti consentiti del lettore non può ripristinare session_status se un livello precedente l’ha rimosso, e un insieme effettivo di strumenti vuoto interrompe l’esecuzione prima che il modello veda l’email. Metti alla prova il lettore prima di collegare la posta: autentica il suo provider, esegui una sonda del modello con il lettore selezionato, poi invia un turno di una riga e pretendi indietro la risposta esatta, l’unico controllo che verifica insieme modello, runtime, sandbox e policy degli strumenti. L’articolo sul sandboxing di OpenClaw copre l’isolamento su cui si basa questo lettore, e l’articolo sulle flotte multi-agente di OpenClaw spiega le regole dell’elenco degli agenti e dei binding che hai appena modificato.

Due token, la configurazione con gcloud e il test del confine

Il comando di configurazione di Gmail scrive il blocco del trasporto, attiva il preset, conserva il mapping limitato che hai applicato prima e usa per impostazione predefinita Tailscale Funnel per l’endpoint push; la modalità serve è limitata alla tailnet e non è una destinazione Pub/Sub raggiungibile pubblicamente, quindi un URL gestito esternamente si imposta con il tunnel disattivato e l’endpoint passato esplicitamente. Due token proteggono due passaggi: il token push autentica Pub/Sub presso il watcher, il token dell’hook autentica il watcher presso OpenClaw tramite un header, e i token nella query string vengono rifiutati, quindi quell’URL push che contiene il token non è un modello da usare per chiamare tu stesso il percorso dell’hook. L’output della configurazione può stampare entrambi i token, quindi oscuralo prima di condividerlo. La strada manuale è breve: seleziona il progetto che possiede il client OAuth di gog, attiva le API Gmail e Pub/Sub, crea il topic, concedi il ruolo di publisher all’account di servizio push di Gmail, poi avvia il watch su quel topic, operazione che non registra alcuna sottoscrizione push e non avvia alcun listener. Poi fai un test. Manda a te stesso un’istruzione inerte da un altro account (la documentazione suggerisce di dire all’agente di seguire un link ed eseguire un comando) e leggi l’esecuzione. Un successo del watcher conferma il trasporto, un 200 dell’hook con un ID esecuzione registra l’ammissione, e qualsiasi tentativo di navigazione verso un link, scrittura di file, comando shell, azione nel browser o registrazione MCP è un controllo del confine fallito. L’articolo sulla prompt injection in OpenClaw descrive il modello di minaccia dietro tutto questo, e il trigger email IMAP applica lo stesso schema di lettore fuori da Google.

Su Diali

Diali ospita OpenClaw come servizio gestito, e ogni cliente esegue il proprio assistente invece di occupare un posto su uno condiviso. La configurazione del runtime viene generata dalle impostazioni della tua dashboard e riscritta a ogni rilascio, mentre sessioni, memoria e file dello spazio di lavoro risiedono su un volume persistente, con snapshot giornalieri e ripristino con un clic disponibili tramite il componente aggiuntivo Backup (incluso in Max). Un endpoint push raggiungibile pubblicamente è il pezzo da concordare con noi, perché l’ingress davanti al tuo assistente è nostro. La pagina sull’hosting OpenClaw di Diali descrive l’assistente ospitato, e la pagina dei prezzi elenca cosa include ogni piano.

• Il preset separa il contesto, mai i permessi.
• Due token, due passaggi, nessuna sostituzione.
• Un 200 dell’hook è un’ammissione, non un riassunto.