2026 OpenClaw Playwright skill-browser auf headless Mac VPS: Chromium Same-Account-Install, Parallelitaets-Obergrenze und Fehler-Runbook (Entscheidungsmatrix und FAQ)

1. Schmerzpunkte: fehlendes Chromium, OOM und Modaldialoge

skill-browser erweitert die Fehlerflaeche um Browser-Subprozesse: Das Gateway kann online sein, waehrend der erste navigate-Aufruf dennoch scheitert. Vier Muster dominieren Postmortems auf kopflosen Mac-VPS-Knoten.

1. Chromium nicht im gleichen Account installiert: CLI und launchd laufen unter verschiedenen Usern; Cache-Pfade spalten sich, Logs melden fehlende Executables oder leere Profile-Verzeichnisse.
2. Exit 137: Zu viele parallele Browser-Contexts; der OOM-Killer beendet Chromium, waehrend das Gateway nur tool timeout ohne Browser-PID sieht.
3. HOME-Spaltung: Interaktiver SSH-Smoke funktioniert, launchd-Sessions nicht — Konfigurationsverzeichnisse sind nicht beschreibbar oder Profile-Locks haengen an der falschen UID.
4. Modale Blockade: Ohne blockedByDialog haengen evaluate-Aufrufe an Cookie-Bannern oder SSO-Dialogen; Snapshots kommen leer zurueck, obwohl navigate HTTP 200 meldet.

Benennen Sie diese Cluster frueh in Runbooks: Ein fehlendes Chromium-Binary ist fast immer ein Account-Problem, nicht ein Playwright-Bug. Exit 137 nach Spitzenlast deutet auf Parallelitaet, nicht auf Netzwerk. Leere Snapshots bei erreichbarer URL deuten auf Modaldialoge oder Anti-Bot-Challenges — beides braucht explizite Policy in der Skill-Konfiguration.

In Incident-Reviews auf Mac Cloud sehen wir haeufig, dass Teams zuerst Netzwerk oder LLM-Provider verdächtigen, obwohl JSONL bereits ENOENT auf Chromium-Pfade oder SIGKILL ohne Stacktrace zeigt. Halten Sie waehrend der Analyse eine einzige toolCallId fest und aendern Sie nicht parallel Gateway-Auth, Skill-Config und Browser-Install. Wer skill-browser neben bestehenden IM-Kanaelen produktiv schaltet, sollte außerdem festlegen, welche URLs erlaubt sind und welche Domains bewusst ausgeschlossen bleiben — das reduziert sowohl Sicherheitsrisiko als auch unnoetige Parallelitaet durch Retry-Schleifen.

Ein fuenftes Muster, das seltener dokumentiert wird: veraltete Playwright- oder Chromium-Caches nach Minor-Upgrades. Symptom ist ein navigate, der sporadisch mit Protocol-Fehlern scheitert, waehrend doctor gruen bleibt. In diesem Fall reicht oft ein gezieltes Loeschen des Browser-Cache-Verzeichnisses unter dem launchd-HOME plus Neuinstallation — immer im selben Account, nie per sudo aus interaktiver Root-Shell.

2. Entscheidungsmatrix: headless Mac VPS vs lokaler Mac vs Docker browser

Lokale Macs eignen sich zum Debuggen von Selektoren und visuellen Flows; fuer 7x24 mit Gateway auf Port 18789 auf derselben Maschine gewinnt headless Mac Cloud. Containerisierte Browser-Stacks finden Sie im Compose-7x24-Runbook.

Teams, die bereits IM-Kanaele auf Mac VPS betreiben, sollten browser skill nicht auf einen separaten Linux-Host auslagern, solange Login-Sessions und Chromium-Profile zum Gateway-User gehoeren muessen. Die Matrix ist bewusst operations-nah formuliert, damit Architektur-Reviews nicht in Tooling-Debatten abdriften.

Fuer kurze Batch-Jobs — etwa naechtliche Preis-Snapshots ohne interaktive IM-Schleife — kann Docker auf demselben Mac VPS sinnvoll sein, wenn Sie Compose-Healthchecks und Ressourcenlimits bereits standardisiert haben. Sobald jedoch ein Agent waehrend eines Telegram-Dialogs live auf eine Seite navigieren muss, gewinnt Co-Location mit dem Gateway: jede zusaetzliche Hop-Schicht erhoeht tail latency und erschwert die Korrelation von sessionId, toolCallId und Channel-Events in JSONL. Lokale Macs bleiben unschlagbar fuer visuelles Selector-Debugging, sollten aber nicht als Produktions-Single-Point dienen: Sleep, VPN-Wechsel und manuelle Modalklicks skalieren nicht zu auditierbarem 7x24-Betrieb.

3. Mac-VPS-Preflight: Node 22, 18789 und Same-Account-HOME

Bevor Sie skill-browser installieren, muss die Gateway-Schicht stabil sein. Halb installierte OpenClaw-Instanzen erzeugen falsche Positives in Browser-Smokes.

• Runtime: Node.js 22 oder neuer; openclaw doctor und openclaw --version ohne Halb-Install-Warnungen.
• Gateway: lsof -i :18789 oder openclaw gateway status zeigt Listener; bei Fehlern das Gateway install Runbook abarbeiten.
• Account-Ausrichtung: UserName und HOME aus dem launchd-plist notieren; Chromium-Install und Skill-Konfiguration muessen unter demselben User laufen.
• Ressourcen und Audit: Mindestens 8 GB RAM und 20 GB freier Disk empfohlen; vor ClawHub-Pull das Skill-Sicherheitsaudit abschliessen.

Notieren Sie die Ausgabe von echo $HOME sowohl in interaktiver SSH-Shell als auch in einer per launchctl asuser simulierten Session. Abweichungen hier sind die haeufigste Ursache fuer „lokal gruen, produktion rot“ bei browser skill.

Planen Sie mindestens zwanzig Prozent freien RAM oberhalb des erwarteten Chromium-Footprints ein. Auf geteilten Mac-Cloud-Knoten konkurrieren browser skill, Gateway und ggf. lokale Embedding-Modelle um denselben Speicherpool. Wenn Sie Ollama oder andere Provider parallel betreiben, dokumentieren Sie in der Kapazitaetsplanung explizit, dass jeder offene Browser-Context realistisch vierhundert bis sechshundert Megabyte kosten kann. Disk-IOPS sind der zweite Engpass: langsames Volume verlaengert Cold Start und erhoeht timeout-bedingte Flakiness bei schweren SPAs.

Vor dem ersten openclaw skills install skill-browser sollte das ClawHub-Audit abgeschlossen sein. Third-Party-Skills mit Shell- oder Dateizugriff erweitern die Angriffsflaeche auf demselben Host, der Ihre Gateway-Tokens und IM-Geheimnisse haelt. Spiegeln Sie die Exec-Gating-Empfehlungen aus dem Skill-Audit-Artikel und behandeln Sie browser skill wie jede andere produktionskritische Erweiterung: versionieren, reviewen, rollback-faehig halten.

4. skill-browser-Parametertabelle: headless, Parallelitaet, Timeout

skill-browser basiert auf Playwright headless Chromium. Die Tabelle ist ein Review-Geruest — nach jedem Upgrade erneut mit openclaw doctor gegen die live Konfiguration halten.

Parallelitaet ist der groesste Hebel fuer Stabilitaet: Ein einzelner Context genuegt fuer die meisten IM-getriggerten Flows. Erhoehen Sie parallel contexts erst, wenn RSS unter 60 Prozent des verfuegbaren RAM bleibt und Snapshot-Erfolgsquoten stabil ueber 95 Prozent liegen.

Bei blockedByDialog gibt es zwei produktionsreife Strategien: dismiss fuer Marketing-Cookie-Banner und Newsletter-Popups, die den Flow nicht blockieren sollen, und fail-fast fuer SSO- oder Payment-Modale, bei denen ein haengender Agent schlimmer ist als ein klarer Fehler an den Nutzer. Dokumentieren Sie die Wahl pro Ziel-Domain im Runbook, damit On-Call nicht bei jedem Incident neu entscheiden muss. Fuer timeout-ms empfiehlt sich ein zweistufiges Modell: niedrigere Defaults fuer interne Tools mit stabilem DOM, hoehere Werte fuer externe Seiten mit schwerem JavaScript — aber nie so hoch, dass die Tool-Queue unter Last einbrennt.

5. Sieben-Schritte-Runbook: Account → Install → Chromium → Sonde → Smoke → launchd

1. Account und HOME ausrichten: launchd-plist UserName pruefen; per SSH als derselbe User anmelden; echo $HOME muss zum plist passen.
2. Versions-Pin und doctor: openclaw.json sichern, openclaw doctor ausfuehren; Upgrades gemaess Mai-Release-Train-Runbook.
3. skill-browser installieren: Nach Audit openclaw skills install skill-browser.
4. Chromium installieren: Im gleichen Account npx puppeteer browsers install chromium; Pfad in Logs notieren.
5. Parameter schreiben: headless, parallel contexts, timeout-ms, blockedByDialog in Skill-Konfiguration.
6. Sonde und Smoke: Port 18789 bestaetigen; feste URL fuer Snapshot; toolCallId in JSONL speichern.
7. launchd-Abnahme: plist laden, Neustart simulieren, Smoke wiederholen — Ergebnis muss identisch sein.

Archivieren Sie Snapshot-Outputs und zugehoerige JSONL-Zeilen im Change-Ticket. So koennen Responder nach Upgrades Regressionen in einem Diff sehen, statt den gesamten Stack neu zu debuggen.

Schritt zwei — Versions-Pinning — verdient besondere Aufmerksamkeit in der 2026.5-Linie: Skill-Laden und exec-Gating wurden strenger. Nach jedem Upgrade nicht nur doctor, sondern auch einen minimalen End-to-End-Flow ausloesen: IM-Nachricht → Agent ruft browser tool → Snapshot zurueck. Vergleichen Sie headless- und blockedByDialog-Defaults mit dem Stand vor dem Upgrade; Drift hier erklaert viele scheinbar „zufaellige“ evaluate-Hangs. Schritt sieben — launchd-Abnahme — ist nicht optional: ein Smoke nur in interaktiver SSH-Shell beweist nichts ueber den Dauerbetrieb nach Reboot oder plist-Reload.

6. Drei messbare Signale: Cold Start, RSS, Snapshot-Erfolgsquote

• Chromium Cold Start: Erster Launch auf Mac Cloud sollte unter acht Sekunden liegen; dauerhaft ueber fuenfzehn Sekunden deutet auf Disk-IO-Engpass oder fehlende Warmup-Policy hin.
• Speichernutzung: Nach Single-Context-Smoke sollten Gateway plus Chromium zusammen unter 60 Prozent des verfuegbaren RAM bleiben.
• Snapshot-Erfolgsquote: Zwanzig Wiederholungen gegen dieselbe URL sollten mindestens 95 Prozent Erfolg zeigen; unter 90 Prozent zuerst Modaldialog-Policy anpassen, nicht sofort Parallelitaet erhoehen.

Binden Sie diese drei KPIs an Ihr bestehendes Paging: Cold-Start-Regression nach Deploy deutet auf fehlendes Chromium oder falschen Cache-Pfad; RSS-Spitzen korrelieren mit parallel contexts; Snapshot-Drift oft mit Anti-Bot oder SSO-Aenderungen auf der Zielseite.

Ergänzen Sie wo moeglich ein einfaches Dashboard: Snapshot-Erfolgsquote pro Stunde, p95 Cold Start und Gateway-RSS nach browser tool. Schwellenwerte gehoeren woertlich ins Runbook — „unter 90 Prozent Snapshot ueber 15 Minuten“ ist pager-wuerdig; „einzelner Timeout“ oft nicht. Teams mit mehreren Ziel-URLs sollten pro URL eigene Baselines fuehren, weil Anti-Bot-Policy je Domain stark variiert.

7. Fehler-Mapping und Schicht-Triage

„Browser-Tool fehlgeschlagen“ sequenziell abarbeiten: Chromium vorhanden → Same-Account-HOME → headless/Parallelitaet → Modale/timeouts. Jede Schicht an JSONL toolCallId haengen.

Vermeiden Sie parallele Aenderungen an Gateway-Auth, Skill-Config und Chromium-Install waehrend eines Incidents. Eine stabile toolCallId-Kette macht Postmortems schneller als Screenshots aus interaktiven Shells.

Layer eins — Chromium vorhanden — pruefen Sie mit demselben User wie launchd: which chromium allein reicht nicht, wenn puppeteer in ein user-spezifisches Cache-Verzeichnis installiert hat. Layer zwei — HOME — vergleichen Sie plist, interaktive Shell und simulierte launchd-Umgebung. Layer drei — Parameter — validieren Sie headless true auf kopflosen Hosts und parallel contexts gegen RAM-Budget. Layer vier — Modale und Netz — blockedByDialog, timeout und ggf. Ziel-URL-Wechsel. Erst wenn layer eins bis drei gruen sind, lohnt tiefe Analyse von DOM oder Anti-Bot auf der Zielseite.

8. Praxisbeispiele: Formulare, Monitoring und IM-Anbindung

Support-Formular-Automatisierung: Ein Agent empfaengt Tickets per Telegram, oeffnet ein internes Formular mit skill-browser, fuellt Felder aus und liefert Screenshot zurueck; SSO-Modale mit fail-fast, damit der Agent nicht in Endlosschleifen haengt.

Wettbewerber-Monitoring: Cron triggert feste Selector-Snapshots in JSONL; parallel contexts bleibt auf 1, um OOM zu vermeiden; Drift in DOM-Struktur faellt ueber Snapshot-Vergleich auf.

Browse-then-Reply: Nutzer fragen per @bot nach Dokumentation; der Agent navigiert zuerst zur Live-Doku, fasst dann zusammen — ideal fuer Seiten mit Login oder clientseitigem Rendering, die reine LLM-Antworten ohne URL-Kontext falsch machen wuerden.

Compliance-Screenshots: Regulatorische oder interne Audits verlangen periodische Nachweise, dass eine oeffentliche Statusseite bestimmten Text enthaelt. Ein cron-getriggerter Flow mit festem Selector und archiviertem Snapshot in JSONL liefert wiederholbare Evidenz — vorausgesetzt parallel contexts bleibt konservativ und die Ziel-URL ist in einer Allowlist. Kombinieren Sie solche Jobs nicht mit interaktiven Peak-Last-IM-Flows auf demselben Knoten ohne RAM-Reserve.

9. FAQ

Frage: Kann skill-browser neben Ollama oder mehreren Providern laufen? Ja; Browser-Subprozesse sind entkoppelt. Setzen Sie in tools.profile eine eigene Parallelitaetsobergrenze und beobachten Sie RSS in gateway status --deep.

Frage: Nach Upgrade auf v2026.5.x erneut abnehmen? doctor, Chromium im gleichen Account neu installieren, minimaler Snapshot-Smoke — siehe Release-Train-Runbook.

Frage: Mac Cloud vs Linux VPS oder Docker? 7x24 mit Gateway co-located: Mac Cloud; kurze Batch-Jobs: Docker moeglich, aber laengere OOM- und Rechte-Triage.

10. Fazit

Erfolgskriterium: skill-browser → Same-Account-Chromium → reproduzierbarer Snapshot ueber Port 18789. Laptop und WSL2 halten selten 7x24; Docker browser auf Linux VPS kaempft haeufig mit /dev/shm und headless-Erkennung. Wer browser skill parallel zu IM-Kanaelen dauerhaft betreiben will, bucht am zuverlaessigsten einen VPSMAC Apple-Silicon-Mac-Cloud-Knoten und fasst Gateway, Chromium-Cache und launchd in einem Runbook zusammen. Docker bleibt fuer kurze Batch-Workloads sinnvoll, ersetzt aber nicht den produktiven headless-Mac-Stack. Weiterlesen: Docker 7x24 und Skill-Audit.