OpenClaw über Gmail auslösen

Sie möchten, dass der Assistent reagiert, wenn E-Mails eintreffen: eine neue Rechnung, eine Support-Anfrage, eine Meldung über ein fehlgeschlagenes Deployment. Die naheliegende Verkabelung, Gmail auf den Agenten zu richten, mit dem Sie ohnehin chatten, erteilt jedem Fremden, der Ihre Adresse kennt, das Wort bei einem Agenten, der Ihre Shell, Ihre Dateien und Ihren Browser in der Hand hat. Der Gmail-Weg von OpenClaw existiert, um genau das zu vermeiden, und er ist eine Kette von Teilen statt eines Schalters.

Wie eine Gmail-Nachricht einen Agenten erreicht

• Google Pub/Sub ist der Transport. Eine Gmail-Watch auf einem Label veröffentlicht Posteingangsereignisse in einem Topic, Pub/Sub pusht sie an den Prozess gog gmail watch serve, und dieser Watcher leitet die E-Mail-Daten an den HTTP-Hook des Gateways weiter. Er lädt nie einen internen HOOK.md-Handler: Das ist der eingehende externe Hook, nicht das prozessinterne Ereignissystem.
• Die Voraussetzungen sind konkret: die gcloud CLI, gog mit Autorisierung für das überwachte Gmail-Konto, aktivierte Hooks in OpenClaw, ein HTTPS-Push-Endpunkt, den Pub/Sub tatsächlich erreichen kann (Tailscale Funnel in der empfohlenen Einrichtung), und ein funktionierendes Sandbox-Backend, dessen Image Sie vor dem ersten Lauf bauen, wenn Sie beim Standard-Backend Docker bleiben.
• Das Gateway startet und erneuert den Watcher selbst, sobald Hooks aktiviert sind und ein Gmail-Konto gesetzt ist; eine Umgebungsvariable schaltet das ab. Betreiben Sie genau einen: Ein zweiter serve-Prozess oder ein manueller run-Befehl auf demselben Listener ist ein Bind-Konflikt, und ein gestarteter Listener beweist nicht, dass die Watch registriert wurde.
• Ein gepushter Batch wird zu einem Agent-Lauf pro E-Mail, da das Mapping über das messages-Array auffächert, begrenzt auf 200 Einträge. Gmail-Pfade erhalten ein größeres Kontingent für den Request-Body, abgeleitet aus dem Byte-Limit pro Nachricht und gedeckelt bei 32 MiB, und eine Upstream-History-Seite zählt History-Einträge, nicht E-Mails, sodass ein Rückstau trotzdem an Grenzen stoßen kann.

Die Sitzung pro Nachricht des integrierten Gmail-Presets trennt den Unterhaltungskontext; sie schränkt weder die Tools noch den Workspace des Ziel-Agenten ein.

Sitzungen pro Nachricht sind keine Berechtigungsgrenze

Das Preset gibt jeder Nachricht ihren eigenen Sitzungs-Schlüssel, sodass die zweite E-Mail die Unterhaltung der ersten nicht lesen kann. Das ist Kontextisolation, und mehr ist es nicht. Wenn kein Mapping eine Agent-ID setzt, löst das Preset auf Ihren Standard-Agenten auf, was bedeutet, dass die E-Mail eines Fremden von dem Agenten zusammengefasst wird, dem Ihr Workspace und Ihre Tools gehören. Ein eigenes Mapping, das auf den gmail-Pfad passt, läuft vor dem Preset, und dort benennen Sie den Reader; die Liste der erlaubten Agent-IDs des Hooks verhindert, dass dieser Endpunkt etwas anderes auswählt. Gmail an einen leistungsfähigeren Agenten zu routen ist erlaubt, aber die Dokumentation bittet Sie, das als Sicherheitsentscheidung zu behandeln: Content-Wrapping an, Ausführung in der Sandbox, nichts gewährt, was über den Bedarf des Workflows hinausgeht.

Der mail_reader-Agent

• Der Reader ist ein zweiter Eintrag in der Agentenliste mit eigenem Workspace und eigenem Modell sowie einer Sandbox mit Modus all, Scope session und ohne Workspace-Zugriff. Jede E-Mail erhält daher eine frische Sandbox, die den Workspace des Host-Agenten nicht erreichen kann, und der Lauf ist von vornherein wegwerfbar.
• Seine Tool-Richtlinie ist das minimale Profil mit einem einzigen erlaubten Tool, session_status, plus einer expliziten Deny-Liste, die die Gruppen für Dateisystem, Runtime und Web sowie die Tools für Browser, Cron, Gateway und Nodes abdeckt. Diese Zulassungsliste pro Agent ist eine absolute Klammer, sodass ein globaler also-allow-Zusatz nicht in den Reader durchsickern kann, und die expliziten Denies halten die beabsichtigte Grenze prüfbar.
• Mit dem Reader wird die Agentenliste zu einer expliziten Flotte, sodass jeder Kanal, der noch Ihrem Haupt-Agenten gehört, sein eigenes Binding braucht, eines pro Kanal, denn es gibt keine kanalübergreifende Wildcard. Die Agenten mit ihren Bindings aufzulisten, bevor Sie neu starten, ist die Prüfung, die einen Kanal ohne Eigentümer findet, und die Zustellung ist aus, sodass Abschlüsse protokolliert statt angekündigt werden.

Eine Regel erwischt viele: Tool-Richtlinien werden nur enger, wenn sich die Ebenen global, Anbieter, Agent und Sandbox kombinieren, daher kann die Zulassungsliste des Readers session_status nicht wiederherstellen, wenn eine frühere Ebene es entfernt hat, und ein leeres effektives Tool-Set bricht den Lauf ab, bevor das Modell die E-Mail sieht. Prüfen Sie den Reader, bevor Sie E-Mail anbinden: Authentifizieren Sie seinen Anbieter, testen Sie das Modell mit ausgewähltem Reader, senden Sie dann eine einzeilige Nachricht und verlangen Sie genau die erwartete Antwort zurück; das ist die einzige Prüfung, die Modell, Runtime, Sandbox und Tool-Richtlinie gemeinsam beansprucht. OpenClaw-Sandboxing erklärt behandelt die Isolation, auf die sich dieser Reader stützt, und Multi-Agent-Flotten in OpenClaw erklärt die Regeln für Agentenliste und Bindings, die Sie gerade geändert haben.

Zwei Tokens, die gcloud-Einrichtung und der Grenztest

Der Gmail-Einrichtungsbefehl schreibt den Transport-Block, aktiviert das Preset, bewahrt das eingeschränkte Mapping, das Sie zuerst angelegt haben, und verwendet standardmäßig Tailscale Funnel für den Push-Endpunkt; der serve-Modus ist nur im Tailnet erreichbar und kein öffentlich erreichbares Pub/Sub-Ziel, daher wird eine extern verwaltete URL mit ausgeschaltetem Tunnel und explizit übergebenem Endpunkt eingetragen. Zwei Tokens sichern zwei Hops: Das Push-Token authentifiziert Pub/Sub gegenüber dem Watcher, das Hook-Token authentifiziert den Watcher gegenüber OpenClaw über einen Header, und Tokens im Query-String werden abgelehnt, sodass diese Push-URL mit Token keine Vorlage ist, um den Hook-Pfad selbst aufzurufen. Die Ausgabe der Einrichtung kann beide Tokens anzeigen, schwärzen Sie sie also, bevor Sie sie teilen. Der manuelle Weg ist kurz: Wählen Sie das Projekt, dem der gog-OAuth-Client gehört, aktivieren Sie die Gmail- und Pub/Sub-APIs, legen Sie das Topic an, gewähren Sie dem Gmail-Push-Dienstkonto die Publisher-Rolle und starten Sie dann die Watch für dieses Topic, was weder ein Push-Abo registriert noch einen Listener startet. Dann testen Sie. Schicken Sie sich von einem anderen Konto eine harmlose Anweisung (die Dokumentation schlägt vor, den Agenten aufzufordern, einem Link zu folgen und einen Befehl auszuführen) und lesen Sie den Lauf nach. Ein Erfolg des Watchers bestätigt den Transport, ein 200 des Hooks mit einer Run-ID dokumentiert die Annahme, und jeder Versuch, einem Link zu folgen, eine Datei zu schreiben, einen Shell-Befehl auszuführen, eine Browser-Aktion auszulösen oder eine MCP-Registrierung vorzunehmen, ist ein fehlgeschlagener Grenztest. Prompt Injection in OpenClaw ist das Bedrohungsmodell hinter all dem, und der IMAP-E-Mail-Trigger ist dasselbe Reader-Muster abseits von Google.

Bei Diali

Diali hostet OpenClaw als verwalteten Dienst, und jeder Kunde betreibt seinen eigenen Assistenten statt eines Platzes an einem geteilten. Die Runtime-Konfiguration wird aus Ihren Dashboard-Einstellungen erzeugt und bei jedem Release neu geschrieben, während Sitzungen, Gedächtnis und Workspace-Dateien auf einem persistenten Volume liegen, mit täglichen Snapshots und Wiederherstellung mit einem Klick über das Add-on Backups (in Max enthalten). Ein öffentlich erreichbarer Push-Endpunkt ist der Teil, den Sie mit uns abstimmen, denn der Ingress vor Ihrem Assistenten gehört uns. Gehostetes OpenClaw bei Diali beschreibt den gehosteten Assistenten, und die Preisseite von Diali listet auf, was jeder Tarif enthält.

• Das Preset trennt Kontext, niemals Berechtigungen.
• Zwei Tokens, zwei Hops, kein Ersatz.
• Ein 200 des Hooks ist die Annahme, keine Zusammenfassung.