openclaw doctor, Dashboard-Token, Bindung nur an 127.0.0.1, gefilterte Webhooks, minimal berechtigte Tokens sowie isolierte Arbeitsverzeichnisse pro Lauf. Vertiefung ohne Anmeldung: Hilfe, Gateway-Healthcheck & LaunchAgent, Discord-Webhook & CI-Zusammenfassung.
① Gateway laut docs.openclaw.ai: doctor, Token und nur Loopback
OpenClaw per curl oder npm i -g openclaw@latest installieren, openclaw onboard, Dashboard öffnen – Details zu Port, Auth und Netzwerk stehen unter docs.openclaw.ai.
openclaw doctor prüft Node (22.16+ / 24 LTS), Binaries, TLS und Proxy. Derselbe Node-Pfad muss für Login-Shell und launchd-Dienst gelten.
Gateway/Dashboard nur auf 127.0.0.1 binden; Webhooks über TLS-Proxy, ssh -L oder Relay – nicht Verwaltung und Welt-Interface auf 0.0.0.0 vermischen. Dashboard-Token nur in Secret-Store oder LaunchAgent-Plist, nie im Repo.
- Token-Sichtbarkeit: Screenshots und Screen-Sharing exponieren oft das Gateway-Token – Rotationsplan mit dokumentiertem Rollout.
- Pfad-Drift: Unterschiedliche
PATH-Einträge für interaktive Shell und Daemon führen zu falschemnodeoder fehlendemopenclaw. - TLS zu GitHub: Firmen-CA über
NODE_EXTRA_CA_CERTSfür den Prozess setzen, der die Checks-API aufruft.
② Webhook anlegen, Secret und Event-Filter
Webhooks: Ziel zeigt per Tunnel/Relay auf 127.0.0.1 am Mac; application/json; starkes Secret. Events minimal: z. B. check_suite, optional pull_request für Lockfile-PRs.
Handler-Filter: Nur completed verarbeiten; nach head_sha entduplizieren; bei PRs Pfade auf Lockdateien (package-lock.json, yarn.lock, pnpm-lock.yaml, Cargo.lock …) einschränken.
Vor Klon/API: HMAC SHA-256 (X-Hub-Signature-256) prüfen – sonst 401, kein Repo-Zugriff.
③ Minimale GitHub-Rechte und Arbeitsverzeichnis-Isolation
Fine-grained PAT oder GitHub App mit Contents: Read, Checks: Write, Metadata: Read – weiteres abschalten bis das Audit mehr verlangt.
Pro Event eigenes Verzeichnis oder git worktree; nach Lauf aufräumen – keine geteilten node_modules zwischen Jobs.
| Maßnahme | Ziel |
|---|---|
| Separates Klon-Verzeichnis | Keine Kreuzkontamination zwischen parallel laufenden Checks |
| SHA aus Payload | Diff bezieht sich auf den auslösenden Commit, nicht auf main vom Vortag |
| Token nur als Umgebungsvariable | Keine PATs in Workflow-YAML oder Shell-History |
| Gemeinsamer Ordner ohne Lock | Race Conditions und falsche Lockfile-Diffs |
④ Lockfile-Scan und Zusammenfassung an Checks zurückgeben
Nach Checkout des Trigger-SHAs: Policy (z. B. git diff der Lockdatei oder Paketmanager---dry-run). Check-Run-Text kurz: Datei, Umfang, PR-Link. Nutzen Sie denselben SHA wie in der Webhook-Payload, nicht einen veralteten Branch-Stand.
Zusammenfassung per Checks API oder Gateway-Relay posten; Retries mit Backoff (2/4/8 s), Grenze setzen; bei Grauzonen neutral + Log-Pfad. Chat-Spiegelung analog Multi-Endpoint-Routing & CI-Zusammenfassung – Checks bleiben Quelle der Wahrheit.
⑤ Häufige Fehler FAQ
Webhook-Lieferung 401 oder 404 trotz erreichbarem Server?
Prüfen Sie, ob der Reverse-Proxy den Pfad /…/webhook abgeschnitten hat, ob der Handler nur auf 127.0.0.1 lauscht aber der Tunnel auf einen anderen Port zeigt, und ob das HMAC-Secret exakt dem Eintrag in GitHub entspricht.
Checks API: 403 „resource not accessible by integration“?
Token oder App fehlt checks:write, das Repository ist nicht autorisiert, oder eine Organisationsrichtlinie blockiert Drittanwendungen. Bei fine-grained PATs jedes Zielrepo einzeln anhaken.
Viele doppelte Läufe nach einem Push?
check_suite feuert mehrfach; deduplizieren Sie mit head_sha und filtern Sie nach action bzw. conclusion. Ergänzend pull_request mit Pfadfilter für Lockfiles.
openclaw doctor warnt vor Node oder Zertifikaten?
LaunchAgent-PATH an die interaktive Shell anpassen; Unternehmens-CA einbinden; als Dienstbenutzer curl -v https://api.github.com testen.
Lockfile-Diff stimmt nicht mit dem PR überein?
Falschen Commit ausgecheckt, veraltetes Arbeitsverzeichnis oder zwischenzeitlich überschriebene Dateien im gemeinsamen Cache – frisch klonen, richtigen SHA aus der Payload verwenden.
Fazit
Fazit (2026): Die Kombination aus docs.openclaw.ai-konformem Gateway auf 127.0.0.1, openclaw doctor, gefilterten Webhooks, minimalen Tokens und isolierten Arbeitsverzeichnissen ist der kleinste stabile Kern für Lockfile-Scans mit Rückmeldung an GitHub Checks. Auf einem dauerhaft erreichbaren Apple-Silicon-Remote-Mac entfallen Laptop-Schlafmodi und wechselnde Heim-IP-Adressen – ideal für Tunnel, feste Ausgangs-IP und stabile Gateway-Automatisierung. Ohne Login-Pflicht für Leser: Startseite, Kaufen, Hilfe, Technik-Blog.
Nächste Schritte – öffentliche Seiten
Hilfe (SSH & Verbindung), Kaufen, Preise und der Technik-Blog mit weiteren OpenClaw-Artikeln.