2026: Self-Hosted GitHub Actions Runner auf Remote-Mac für OpenClaw CI — Nur-Lesen-Webhooks, macOS-Label-Pools und M4-Parallelität (Lobster-Workflows + Fehlerbehebung-FAQ)

Wer einen OpenClaw-Fork oder ein Plugin pflegt, steht 2026 oft vor zwei parallelen Spuren: Die OpenClaw-CI erwartet echtes macOS für macos-node, macos-swift und checks-node-compat-node22; parallel steigen die Minuten und Warteschlangen bei von GitHub gehosteten macOS-Runnern. Dieser Leitfaden behandelt ausschließlich einen Self-Hosted GitHub Actions macOS Runner auf einem dedizierten Remote-Mac, das Mapping von macOS-Label-Pools auf diese Lanes sowie Nur-Lesen-Webhooks und mehrstufige Lobster-Workflows für Fehlertriage — nicht die Gateway-Installation auf Port 18789, keinen Sechs-Regionen-Vergleich (siehe unseren Runner-Regionen- & TCO-Artikel). Preise: Mac-mini-Preise; Bestellung USA Ost / West: USA Ost, USA West; Runner-Betrieb: Hilfezentrum.

1) Gehostete macOS-Runner vs. Remote-Mac Self-Hosted: Entscheidungstabelle für OpenClaw CI

Laut OpenClaw-CI-Dokumentation führt macos-node TypeScript-Tests aus, wenn macOS-bezogene Quellen ändern; macos-swift deckt Swift-Lint/Build/Test ab; manuelles workflow_dispatch umgeht den intelligenten Scope und startet den vollen Graphen (inkl. Node-22-Kompatibilität). Upstream nutzt standardmäßig Blacksmith-Runner der Klasse macos-latest — für das Hauptrepo in Ordnung, aber Fork-Maintainer, die sich nicht auf diese Queue verlassen können, brauchen eigene macOS-Tags.

Gehostetes macOS passt zu seltenen PRs; Self-Hosting auf einem Remote-M4 tauscht feste Miete gegen persistente node_modules und DerivedData — besser für tägliches main, Plugin-Contract-Shards und Teams, die ein lokales pnpm check auf kontrollierter Hardware wollen. Für Multi-Region-Knoten und TCO Tag–Monat lesen Sie den Regionen- & TCO-Artikel; hier verdrahten wir nur OpenClaw-Lanes. Langfristiges Gateway-/Agent-Deployment steht in dem OpenClaw-Remote-Mac-Praxisleitfaden (ein Satz: Gateway bedient Chat/Tools; CI-Runner bedienen Compile/Test).

Ein weiteres Signal: Der preflight-Job Ihres Forks plant bei jedem Plugin-Touch macOS-Lanes, aber gehostete Runner leeren Caches zwischen Jobs — TypeScript und Swift laden länger als sie testen. Ein Remote-Mac mit warmem pnpm-Store und DerivedData verkürzt oft die Laufzeit, auch bei ähnlicher CPU — messen Sie auf Ihrem Repo, bevor Sie Seats budgetieren.

2) Umgebungs-Checkliste: Xcode CLT, Node 22, CI-Benutzer-Isolation

OpenClaw führt die meisten Node-Shards auf Linux aus, aber macos-node und checks-node-compat-node22 verlangen Node 22 (siehe CI-Docs und lokale pnpm check-Parität). Auf dem Runner-Host:

• Xcode Command Line Tools plus vom Team eingefrorene Xcode-Minor-Version; die Swift-Lane braucht volles Xcode, nicht nur CLT.
• Node 22.x via fnm oder mise in der CI-User-Shell; weiterhin actions/setup-node in Workflows.
• pnpm wie Upstream-packageManager; Cache im CI-Home, nicht im täglichen Dev-Account.
• Dedizierter Unix-User (z. B. runner) für actions-runner — nicht derselbe User wie Browser-/Chat-Secrets.
• Ressourcen-Obergrenzen: memory_pressure beobachten; zweiten Job auf 24 GB erst nach Messung parallelisieren.

Plattform-APIs: Apple Developer Documentation; Node-Policy: nodejs.org.

3) Runner-Registrierung & macOS-Label-Pool (HowTo)

Folgen Sie dem offiziellen Self-Hosted-Runner-Leitfaden. Für einen OpenClaw-Fork Upstream-Jobs auf explizite Labels mappen — nicht nur ein vages self-hosted.

# in ~/actions-runner
./config.sh --url https://github.com/YOUR_ORG/YOUR_FORK \
  --token YOUR_REGISTRATION_TOKEN \
  --labels self-hosted,macOS,ARM64,openclaw-macos-node,openclaw-m4-16 \
  --name nuv-openclaw-macos-node-01

sudo ./svc.sh install
sudo ./svc.sh start

Label-Pool (nach Lane):

• openclaw-macos-node — Upstream-macos-node (TypeScript/Vitest macOS-Pfade).
• openclaw-macos-swift — macos-swift; mehr CPU/RAM — kein Standard-Parallel mit node auf 16 GB.
• openclaw-node22 — optional für Dispatch-Compat oder lokalen pnpm check-Smoke.
• openclaw-m4-16 / openclaw-m4-24 — Hardware-Stufe für Matrizen und Kapazitätsplanung.

jobs:
  macos-node:
    runs-on: [self-hosted, macOS, openclaw-macos-node]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'pnpm'
      - run: pnpm install --frozen-lockfile
      - run: pnpm test --filter macos-relevant

Für Codesign/Notarisierung concurrency: { group: codesign-macos, cancel-in-progress: false }, damit zwei Jobs nie gleichzeitig Keychains entsperren. SSH/Runner-Hinweise: Hilfezentrum.

Org- vs. Repo-Runner: Ein Einzel-Repo-Fork kann einen Repo-Runner mit den Labels oben nutzen. Teilen mehrere Plugins eine Abrechnungsgruppe, erwägen Sie einen Organisations-Runner mit Zugriff nur auf kontrollierte Forks und Runner-Gruppen (Enterprise), damit Experiment-Repos keine Swift-Lane-Maschinen kapern.

Upgrades: Runner-App-Version im Runbook pinnen; nach jedem GitHub-Runner-Release Jobs abarbeiten (./svc.sh stop), Binaries upgraden, neu starten, Idle bestätigen vor Auto-Zuweisung. Veraltete Runner erklären oft „lokal ok, CI rot“ bei Protokolländerungen.

4) OpenClaw CI / Dispatch & Nur-Lesen-Webhooks anbinden

Upstream-preflight bei push/PR beibehalten; nur macOS-runs-on auf Ihren Pool ändern. Für volle Validierung den dokumentierten manuellen Dispatch nutzen:

gh workflow run ci.yml --ref main
gh workflow run ci.yml --ref main -f target_ref=your-branch -f include_android=true

Nur-Lesen-Webhook-Reasoning (phasenweise): Für Fehlertriage zuerst Nur-Lesen-Events abonnieren — workflow_run.completed, check_run.completed, workflow_job.completed — und Metadaten persistieren (Repo, Branch, Conclusion, URLs). In Phase 0 kein Contents-Schreiben oder Auto-Merge. Nach Signaturprüfung Log-URLs oder Actions-API-Lesescopes; Kommentare/Labels nur mit Freigabe-Richtlinie.

Beim Receiver nur stabile Felder loggen: workflow_run.id, head_branch, conclusion, HTML-URLs zur Run. HMAC-Fehler getrennt von Auth-Fehlern. Mit Lobster diese Felder als JSON-stdin — keine vollen Webhook-Bodies in Chat-Prompts, wo ein PR-Titel die Tool-Auswahl beeinflussen könnte.

5) M4 16 GB / 24 GB Parallelität — Spickzettel (Einzelmaschinen-Label-Pool)

Pragmatische Hinweise für OpenClaw-macOS-Lanes (kein SLA; stark repo-abhängig). Für zusätzliche Seats oder Regionen den TCO-Artikel — kein Sechs-Regionen-Tabelle hier.

Nuvcloud bietet Multi-Node-M4-Bare-Metal mit RAM/SSD-Upgrades — gut für feste CI-Seats. Verfügbarkeit und Preis: Preise und Bestellseiten; wir versprechen hier keine Queue-SLAs.

Bei SSD-Dimensionierung drei Wachstumskurven einplanen: Xcode DerivedData, pnpm-Store und GitHub-Actions-Arbeitsverzeichnisse unter _work/. Ein 256-GB-Basis-SKU kann für einen Single-Lane-Node-Fork mit wöchentlichem deriveddata-Cleanup reichen; Swift-lastige Forks sollten 512 GB oder das 1-TB-Add-on im Preis-Assistenten planen. Speicherdruck auf 16 GB zeigt sich oft als beendete node-Kinder während Vitest — bei Jetsam in Console Swift auf einen 24-GB-Host verlagern statt Test-Shards zu verkleinern.

6) Lobster-Workflow: reproduzierbare CI-Fehlerlog-Triage

Lobster fasst mehrstufige Tool-Ketten zu einem deterministischen Aufruf mit Freigabepunkten und resumeToken zusammen — ideal für „CI rot → Logs holen → klassifizieren → menschlich OK → Zusammenfassung posten“ statt LLM-Freestyle-Tools. alsoAllow: ["lobster"] in der Agent-Config aktivieren, dann Pipeline starten.

{
  "action": "run",
  "pipeline": "exec --json --shell 'gh run list --workflow ci.yml --limit 5 --json databaseId,conclusion,headBranch' | exec --stdin json --shell 'gh run view $ID --log-failed' | exec --stdin json --shell 'node scripts/ci-triage-summarize.mjs' | approve --preview-from-stdin --limit 3 --prompt 'Zusammenfassung an On-Call-Kanal senden?'",
  "timeoutMs": 120000,
  "maxStdoutBytes": 512000
}

Schritte in einer .lobster-Workflow-Datei trennen: collect → classify → approval → notify (siehe Lobster „workflow files“). Bei Status needs_approval fortsetzen mit:

{
  "action": "resume",
  "token": "<resumeToken>",
  "approve": true
}

Reproduzierbare Triage-Gewohnheiten: Pro Fehler run_id, auslösendes Label (z. B. openclaw-macos-node) und Hash des ersten stderr-Blocks im Team-Wiki loggen. Lobster-JSON vor Issue-Posts bereinigen — Secrets leaken manchmal in Log-Snippets. Bei Timeout timeoutMs erhöhen oder „Logs holen“ von „LLM zusammenfassen“ trennen. 7-Tage-Nur-Lesen-Archiv pro fehlgeschlagener Run, um Flaky von echten Regressionen zu trennen.

Viele Teams halten zwei Pipelines: einen schnellen Lobster-Flow nur zur Klassifikation (Node vs. Swift vs. Infra) und einen langsamen, der nach menschlicher Freigabe volle Logs holt — wie OpenClaws CI-Philosophie (günstiges Preflight, teure Lanes nur bei Bedarf) und ohne Token-Verschwendung bei grünen Runs.

Nutzen Sie gh bereits in CI, gilt derselbe PAT-Scope auf dem Runner-Host für Lobster: in Phase 0 auf actions:read und metadata:read beschränken. PAT rotieren wenn Mitarbeitende gehen; Registrierungstoken nie als API-Credential wiederverwenden.

7) FAQ

F1: Runner zeigt Offline?
launchd, Token-Ablauf, voller Disk prüfen. Unter GitHub → Einstellungen → Actions → Runners entfernen und config.sh erneut ausführen; siehe Self-Hosted-Runner-Doku.

F2: macos-node meckert über Node?
Node 22 auf dem Host, setup-node und checks-node-compat-node22 angleichen; veraltete globale npm-Caches ggf. leeren.

F3: Swift / SDK nicht gefunden?
Volles Xcode installieren, sudo xcodebuild -license accept; macos-swift nie auf reinen CLT-Hosts.

F4: Nur-Lesen-Webhook bei 403?
Secret, TLS, Reverse-Proxy-Pfad, App-Event-Berechtigungen prüfen; Gateway darf PR-Text nicht als Befehl ausführen.

F5: openclaw doctor vs. rote CI?
doctor = Install/Gateway-Gesundheit; CI-Fehler in Actions-Logs. Lobster + gh run view, nicht Onboard-Docs, für Workflow-Debug.

F6: macOS überspringen und nur Linux?
Ja für reine Node/Docs-PRs, aber vor Merge von macOS/Swift-Änderungen mindestens einen vollen workflow_dispatch-Graphen — sonst Abweichung vom Upstream-preflight.

F7: Einen Runner für Upstream und Fork teilen?
Nicht empfohlen — Runner-Gruppen und Secrets trennen, damit untrusted Fork-Skripte kein Upstream-Signing-Material erreichen.

F8: Lobster invalid JSON?
Jeder Pipeline-Schritt muss JSON auf stdout liefern; maxStdoutBytes erhöhen; keine menschlichen Logs ohne --json in den nächsten Schritt.

F9: Gehostet und Self-Hosted mischen?
Ja — z. B. PR auf gehostet, main-macos-swift Self-Hosted via if: oder getrennte Workflow-Dateien.

Weitere Beiträge: Blog-Index. Für regionsbezogene Abrechnung und parallele Seats weiter mit dem Runner-Regionen- & TCO-Leitfaden.