Déclencher OpenClaw depuis Gmail

Vous voulez que l’assistant réagisse quand un e-mail arrive : une facture, une demande de support, un avis de déploiement en échec. Le câblage évident, brancher Gmail sur l’agent avec lequel vous discutez déjà, donne à n’importe quel inconnu connaissant votre adresse un tour de parole sur un agent qui détient votre shell, vos fichiers et votre navigateur. Le chemin Gmail d’OpenClaw existe pour éviter cela, et c’est une chaîne de pièces plutôt qu’un interrupteur.

Le trajet d’un e-mail Gmail jusqu’à un agent

• Google Pub/Sub sert de transport. Une surveillance Gmail posée sur un libellé publie les événements de boîte de réception vers un sujet, Pub/Sub les pousse vers le processus gog gmail watch serve, et ce guetteur transmet les données de l’e-mail au hook HTTP de la passerelle. Il ne charge jamais de gestionnaire HOOK.md interne : c’est le hook externe entrant, pas le système d’événements en processus.
• Les prérequis sont précis : la CLI gcloud, gog autorisé sur le compte Gmail surveillé, les hooks activés dans OpenClaw, un point de terminaison HTTPS que Pub/Sub peut réellement atteindre (Tailscale Funnel dans la configuration recommandée), et un backend de bac à sable fonctionnel, dont vous construisez l’image avant le premier essai si vous restez sur le backend Docker par défaut.
• La passerelle démarre et renouvelle le guetteur elle-même dès que les hooks sont activés et qu’un compte Gmail est défini, avec une variable d’environnement pour s’en retirer. N’en exécutez qu’un : un second processus serve ou une commande run manuelle sur le même écouteur crée un conflit de port, et un écouteur démarré ne prouve pas que la surveillance a été enregistrée.
• Un lot poussé devient une exécution d’agent par e-mail, car le mappage se déploie sur le tableau des messages, dans la limite de 200 éléments. Les chemins Gmail reçoivent une allocation de corps de requête plus large, dérivée de la limite d’octets par message et plafonnée à 32 Mio, et une page d’historique amont compte des enregistrements, pas des e-mails, donc un retard important peut encore toucher les limites.

La session par message du préréglage Gmail intégré sépare le contexte de conversation ; elle ne restreint ni les outils ni l’espace de travail de l’agent ciblé.

Une session par message n’est pas une frontière de permissions

Le préréglage donne à chaque message sa propre clé de session, si bien que le deuxième e-mail ne peut pas lire la conversation du premier. C’est de l’isolation de contexte, et rien de plus. Si aucun mappage ne fixe d’identifiant d’agent, le préréglage retombe sur votre agent par défaut, donc l’e-mail d’un inconnu est résumé par l’agent qui détient votre espace de travail et vos outils. Un mappage personnalisé correspondant au chemin gmail passe avant le préréglage, c’est là que vous nommez le lecteur, et la liste d’identifiants d’agents autorisés empêche ce point de terminaison d’en choisir un autre. Router Gmail vers un agent plus capable reste permis, mais la documentation demande d’en faire une décision de sécurité : encadrement du contenu externe actif, exécution en bac à sable, rien de plus que les outils utiles au flux.

L’agent mail_reader

• Le lecteur est une seconde entrée de la liste d’agents, avec son propre espace de travail et son propre modèle, et un bac à sable réglé en mode all, portée session, sans accès à l’espace de travail. Chaque e-mail obtient donc un bac à sable neuf qui n’atteint pas l’espace de travail de l’agent hôte, et l’exécution est jetable par construction.
• Sa politique d’outils est le profil minimal avec un seul outil autorisé, session_status, plus une liste de refus explicite couvrant les groupes système de fichiers, runtime et web ainsi que les outils navigateur, cron, passerelle et nœuds. Cette liste d’autorisation par agent est un verrou absolu : un ajout global ne peut pas fuiter jusqu’au lecteur, et les refus explicites rendent la frontière voulue auditable.
• Ajouter le lecteur transforme la liste en flotte explicite, donc chaque canal que votre agent principal détient encore a besoin de sa propre liaison, une par canal, car il n’existe pas de joker inter-canaux. Lister les agents avec leurs liaisons avant de redémarrer est le contrôle qui attrape un canal sans propriétaire, et la livraison est désactivée, donc les fins d’exécution sont journalisées plutôt qu’annoncées.

Une règle prend beaucoup de monde à revers : les politiques d’outils ne font que se resserrer à mesure que les couches globale, fournisseur, agent et bac à sable se combinent, donc la liste d’autorisation du lecteur ne peut pas restaurer session_status si une couche antérieure l’a retiré, et un ensemble d’outils effectif vide interrompt l’exécution avant que le modèle voie l’e-mail. Prouvez le lecteur avant de brancher le courrier : authentifiez son fournisseur, sondez le modèle en sélectionnant le lecteur, puis envoyez un tour d’une ligne en exigeant la réponse exacte, seul contrôle qui éprouve ensemble le modèle, le runtime, le bac à sable et la politique d’outils. Le sandboxing OpenClaw expliqué couvre l’isolation sur laquelle ce lecteur s’appuie, et Les flottes multi-agents OpenClaw explique les règles de liste et de liaison que vous venez de modifier.

Deux jetons, la configuration gcloud et le test de frontière

La commande de configuration Gmail écrit le bloc de transport, active le préréglage, préserve le mappage restreint appliqué au préalable et choisit Tailscale Funnel par défaut pour le point de poussée ; le mode serve reste interne au tailnet et n’est pas une cible Pub/Sub publiquement joignable, donc une URL gérée à l’extérieur s’indique avec le tunnel désactivé et le point de terminaison passé explicitement. Deux jetons gardent deux sauts : le jeton de poussée authentifie Pub/Sub auprès du guetteur, le jeton de hook authentifie le guetteur auprès d’OpenClaw via un en-tête, et les jetons en chaîne de requête sont rejetés, si bien que cette URL de poussée porteuse de jeton n’est pas un modèle pour appeler vous-même le chemin des hooks. La sortie de configuration peut afficher les deux jetons, alors caviardez-la avant de la partager. La voie manuelle est courte : sélectionner le projet qui possède le client OAuth de gog, activer les API Gmail et Pub/Sub, créer le sujet, accorder le rôle de publication au compte de service de poussée Gmail, puis démarrer la surveillance sur ce sujet, ce qui ne crée aucun abonnement de poussée et ne lance aucun écouteur. Ensuite, testez. Envoyez-vous depuis un autre compte une instruction inerte, la documentation propose de demander à l’agent de suivre un lien et d’exécuter une commande, puis lisez l’exécution. Un succès du guetteur n’accuse que le transport, un 200 du hook avec un identifiant d’exécution n’enregistre que l’admission, et toute tentative de navigation vers un lien, d’écriture de fichier, de commande shell, d’action navigateur ou d’enregistrement MCP est un échec du test de frontière. L’injection de prompt dans OpenClaw est le modèle de menace derrière tout cela, et Le déclencheur e-mail IMAP est le même motif de lecteur hors de Google.

Sur Diali

Diali héberge OpenClaw en service géré, et chaque client fait tourner son propre assistant plutôt qu’une place sur un assistant partagé. La configuration d’exécution est générée à partir de vos réglages du tableau de bord et réécrite à chaque version, tandis que les sessions, la mémoire et les fichiers de l’espace de travail vivent sur un volume persistant, avec des instantanés quotidiens et une restauration en un clic grâce à l’option Sauvegardes (incluse avec Max). Un point de poussée joignable publiquement est la pièce à convenir avec nous, puisque l’entrée réseau devant votre assistant nous appartient. OpenClaw hébergé sur Diali décrit l’assistant hébergé, et Tarifs Diali détaille ce que contient chaque forfait.

• Le préréglage sépare le contexte, jamais les permissions.
• Deux jetons, deux sauts, aucune substitution.
• Un 200 de hook vaut admission, pas résumé.