Teams, die OpenClaw auf einem Remote-Mac als Gateway betreiben, wollen CI-Build-Zusammenfassungen zuverlässig in Discord sehen – ohne breite Bot-Rechte und ohne dass Geheimnisse in Repositories landen. Dieser Leitfaden liefert reproduzierbare Schritte für Installation (curl oder npm), openclaw onboard, Dashboard, Incoming-Webhooks, curl-Validierung, ein JSON-Embed-Mapping sowie Rate-Limits und Retries. Vertiefung ohne Login: Hilfe, Telegram/Slack am Gateway, Installations-Fehlersuche.

① Umgebungsvoraussetzungen und Minimalrechte-Prinzip

Node.js für OpenClaw 2026: typisch 22.16+ oder 24 LTS. Gleiche Version in Login-Shell und launchd-Gateway prüfen, sonst schlägt der Dienst fehl. Webhook-URL nur als DISCORD_WEBHOOK_URL / Secret / CI-Variable – nie ins Repo oder ungekürzt loggen.

  • Pfad-Drift: Unterschiedliche PATH-Einträge für Login-Shell und Daemon führen zu falschem node oder fehlendem openclaw.
  • Token-Sichtbarkeit: Dashboard, Screen-Sharing und Support-Screenshots exponieren Gateway-Tokens – Rotation planen.
  • Webhook-Scope: Incoming Webhooks schreiben nur in einen Kanal; das minimiert Rechte gegenüber vollwertigen Bots und erleichtert Audits.

curl-Installer vs. npm i -g openclaw@latest: eine Variante pro Host festlegen.

Kriterium curl npm global
Isolation Festes Präfix npm-Prefix / Rechte
Upgrade Skript erneut npm update -g
Proxy-TLS CA-Bundle nötig gleiches Bundle
Einsatz Gateway-Server Dev-Laptop

openclaw onboard, dann Dashboard (Bind, Port, Token). Siehe Gateway-Healthcheck & LaunchAgent.

Mit openclaw doctor lässt sich die Laufzeitumgebung prüfen; die ausgegebene Version mit den Release-Notes abgleichen. Dokumentieren Sie, ob das Gateway nur auf 127.0.0.1 oder hinter einem Reverse-Proxy mit mTLS lauscht – daraus ergeben sich getrennte Checklisten für Firewall- und Secret-Rotation.

② Discord-Webhook anlegen und auf dem Gateway binden

Discord: Kanal → Integrationen → Webhooks → Incoming Webhook, URL kopieren. Am Mac DISCORD_WEBHOOK_URL für den Gateway-Prozess setzen (Schlüssel je nach Plugin-Version laut Release-Docs).

Erst kurzen Testpost, dann CI. Erwartung: HTTP 204.

export DISCORD_WEBHOOK_URL='https://discord.com/api/webhooks/…' curl -sS -o /dev/null -w "%{http_code}\n" \ --connect-timeout 5 --max-time 20 \ -H "Content-Type: application/json" \ -d '{"content":"OpenClaw-Gateway-Probe OK"}' \ "$DISCORD_WEBHOOK_URL"

Bei TLS/Proxy: HTTPS_PROXY, NO_PROXY und CA unter dem Dienstbenutzer wie im Betrieb testen. Optional CI → interner Relay auf dem Mac → Discord.

③ CI-Build-Zusammenfassung: Payload-Vorlage und Feldzuordnung

Embeds für Repo, Branch, Commit, Status; description kurz halten. Farbe z. B. 3066993 (OK) / 15158332 (Fail).

CI-Metrik Quelle (Beispiel) Discord-Feld
Repository / Workflow GITHUB_REPOSITORY oder Pipeline-Name embeds[].title oder Feldname „Projekt“
Branch GITHUB_REF_NAME / CI_COMMIT_REF_NAME Feld „Branch“ in fields
Commit Kurz-SHA via git rev-parse --short HEAD description mit Link zur Web-UI
Status / Dauer Exit-Code und SECONDS color + Text in description
Runner-Host Hostname des Remote-Mac optionales Feld „Knoten“ für Betrieb
PAYLOAD=$(printf '%s' '{"embeds":[{"title":"CI-Zusammenfassung","description":"acme/app main @ a1b2c3d — success — 3m12s","color":3066993}]}') curl -sS --connect-timeout 5 --max-time 20 -X POST "$DISCORD_WEBHOOK_URL" \ -H "Content-Type: application/json" -d "$PAYLOAD"

Optional: CI → interner HTTP auf dem Mac → Discord (PII-Filter, Signatur).

Unter GitHub Actions entsprechen die Variablen oft GITHUB_REPOSITORY, GITHUB_REF_NAME und GITHUB_SHA; GitLab nutzt CI_PROJECT_PATH, CI_COMMIT_REF_NAME und CI_COMMIT_SHORT_SHA. Mappen Sie immer dieselben Namen in Staging und Produktion, damit Playbooks nicht auseinanderlaufen.

④ Signatur, Ratenbegrenzung und Parameter für Wiederholungen

Webhook-URL = geteilter Schlüssel; Relay mit HMAC möglich. username/avatar_url für Umgebungen.

Bei 429 Retry-After + Jitter. curl: --connect-timeout 5 --max-time 20, max. 3 Versuche, Pause 2/4/8s. HTTPS_PROXY/NO_PROXY für Runner und Gateway gleich halten.

Operativ lohnt es sich, fehlgeschlagene Webhook-Posts mit Zeitstempel und HTTP-Status in die Job-Zusammenfassung zu schreiben, damit On-Call und Entwickler dieselbe Spur sehen. Wenn mehrere Repositories einen Kanal teilen, vereinbaren Sie ein Präfix im Embed-Titel, um Quelle und Umgebung sofort zu erkennen.

Parameter Empfohlener Startwert Stabilitätsziel
Max. POST-Versuche 3 Keine Endlosschleifen bei dauerhaftem Ausfall
Backoff-Sequenz 2s / 4s / 8s + Zufallsanteil Entkopplung paralleler Jobs
Connect-Timeout 5s Schnelles Fail bei blockiertem SYN
Gesamt-Timeout 15–20s Pipeline hängt nicht an hängenden TLS-Handshakes
429-Behandlung Retry-After strikt einhalten Respekt vor API-Quoten

⑤ Häufige Fehler FAQ (403 / 429 / Timeout)

HTTP 403 Forbidden von der Webhook-URL?

Webhook gelöscht, URL gekürzt oder Rechte fehlen – neu anlegen und Secret aktualisieren.

HTTP 429 Too Many Requests trotz weniger Builds?

Matrix multipliziert Posts – zusammenfassen oder Relay; Retry-After beachten.

Timeout oder TLS-Fehler nur auf dem Remote-Mac?

Proxy/DNS/CA für Shell vs. launchd vergleichen; curl -v als Dienstuser.

HTTP 204, aber kein neuer Beitrag im Kanal?

Falsche URL, leere content/embeds, archivierter Kanal oder Thread.

Fazit

Fazit (2026): Node, onboard, Dashboard und Webhook bilden die kurze Schleife für Build-Sichtbarkeit. Mit gemietetem Apple-Silicon-Remote-Mac laufen Gateway und Ausgangsnetz stabiler als auf schlafenden Laptops. Ohne Login: Startseite, Kaufen, Hilfe, Technik-Blog.

Discord × OpenClaw × Remote-Mac

Nächste Schritte – ohne Login

Hilfe, Kaufen, Startseite und Technik-Blog mit weiteren Gateway-Artikeln.

Remote-Mac mieten Hilfe: SSH & Verbindung OpenClaw-Artikel
Apple-Silicon
Gateway fest im Rechenzentrum
CI-Benachrichtigungen