2026 OpenClaw MeshMac in der Praxis: Google Chat Space Webhook — minimal reproduzierbare Schritte für Mehrknoten-Build-Status und Mehrkanal-Benachrichtigung

Drei typische Bruchstellen

1. Geheimnis-Splitting: Jeder Runner besitzt eine Kopie der Chat-URL — Rotation und Audits werden unmöglich.
2. Egress-Blindheit: chat.googleapis.com ist vom Gateway aus gesperrt, während Shell-Tests vom Laptop funktionieren.
3. Retry-Stürme: Flaky Netz oder doppelte Events erzeugen Spam im Raum, weil keine Idempotenz über provider_run_id existiert.

Gateway-Installation und Token

Folgen Sie der Gateway-first-Topologie: ein Host — Bastion, kleine Linux-VM oder dedizierter Mac — führt OpenClaw-Dienste, besitzt ausgehende Webhooks und liest Geheimnisse aus einem versiegelten Verzeichnis. Builder-Knoten enqueuen Ereignisse; sie speichern nicht jeweils die Chat-URL. Details zum Rollout mehrerer Knoten: Deploy, Installation und Config-Sync.

Setzen Sie OPENCLAW_CONFIG_ROOT, schließen Sie Onboarding ab und fahren Sie Health-Checks, damit der Daemon dieselbe Umgebung sieht wie Ihre CI-Jobs. Legen Sie die Webhook-Ziel-URL nach /etc/openclaw/secrets.d/google-chat/build-status.url mit Modus 0440, Owner root, Gruppe openclaw-notify.

Checkpoint A — Dateirechte

sudo install -d -m 0750 -o root -g openclaw-notify /etc/openclaw/secrets.d/google-chat
sudo sh -c 'umask 077; cat > /etc/openclaw/secrets.d/google-chat/build-status.url' <<'EOF'
https://chat.googleapis.com/v1/spaces/SPACE/messages?key=KEY&token=TOKEN
EOF
sudo chown root:openclaw-notify /etc/openclaw/secrets.d/google-chat/build-status.url
sudo chmod 0440 /etc/openclaw/secrets.d/google-chat/build-status.url

Zitierfähig: POSIX 0440 trennt lesende Notify-Prozesse vom interaktiven Admin-Konto; Rotation bleibt ein install-Schritt ohne Repo-Änderung.

Google Chat Incoming Webhook Konfiguration

Im Ziel-Google Chat Raum die Integration Incoming Webhook hinzufügen, benennen (Repo oder Pool), die generierte HTTPS-URL einmalig kopieren. Die Parameter key und token wirken wie ein Bearer. Leck → Webhook widerrufen und neu anlegen; es gibt keine Teilrotation.

• Getrennte Räume je Umgebung, damit Staging nicht „grün“ in den Executive-Produktionsraum postet.
• Egress: vom Gateway-Shell mit denselben HTTPS_PROXY-Variablen wie der Daemon testen.
• Admin-Richtlinie: blockiert Workspace Custom-Webhooks, genehmigte Chat-App oder kontrollierter HTTP-Endpunkt — weiterhin ein zentraler Absender.

Checkpoint B — Erreichbarkeit

export HTTPS_PROXY="${HTTPS_PROXY:-}"
curl -sS -o /dev/null -w "%{http_code}\n" -I "https://chat.googleapis.com/"

Ein Google-404 auf nacktem GET ist üblich; TLS-Fehler oder Proxy-403 müssen vor JSON-Debugging verschwinden.

Nachrichten-Payload-Vorlage

Kleinste zuverlässige Nutzlast: UTF-8 JSON mit Feld text. Cards können folgen, sobald Plain-Text stabil zugestellt wird.

export CHAT_URL="$(sudo cat /etc/openclaw/secrets.d/google-chat/build-status.url)"
curl -sS -X POST "$CHAT_URL" \
  -H 'Content-Type: application/json; charset=UTF-8' \
  -d '{"text":"MeshMac-Gateway-Probe: OK von '"$(hostname -s)"'"}'

Checkpoint C — Nachricht sichtbar innerhalb weniger Sekunden. API-Fehlerobjekt pretty-printen und Body fixen, bevor Automation läuft. Produktionszeile: Status-Label, mesh_node_id, kurzer Commit, Run-URL als Link statt Logdump.

Kennzahl: Halten Sie Text unter den Chat-Längenlimits; lange Artefaktlisten gehören in den Provider, nicht in den Raum.

Mehrknoten-Status-Aggregation (Beispiel)

Drei MeshMac-Builder beenden Jobs in derselben Minute. Jeder Runner publiziert einen normalisierten Datensatz in Redis, NATS oder der OpenClaw-Task-Fabric. Der Gateway-Consumer mappt Provider-Payloads vor dem Rendern von text:

Beispielzeile (ein POST):

✅ ios-release · main · abc1234 · <https://github.com/org/repo/actions/runs/18451203> · Knoten mm-pool-2

Doppelte provider_run_id+state im Gateway deduplizieren — konsistent mit Warteschlangen-Retries, unabhängig vom erneuten CI-Lauf.

Authentifizierung und Retry-FAQ