2026 OpenClaw Playwright skill-browser sur Mac VPS headless : installation Chromium même compte, plafond parallèle et runbook erreurs (matrice décision et FAQ)

1. Irritants : Chromium absent, OOM et modales bloquantes

skill-browser étend la surface de panne aux sous-processus navigateur : la passerelle peut être en ligne tandis que le premier navigate échoue encore. Quatre motifs dominent les post-mortems sur nœuds Mac VPS sans écran.

1. Chromium non installé sous le même compte : CLI et launchd tournent sous des utilisateurs différents ; caches scindés, journaux signalent exécutable introuvable ou profils vides.
2. Exit 137 : trop de contextes parallèles ; le tueur OOM arrête Chromium pendant que la passerelle ne voit qu un tool timeout sans PID navigateur.
3. Scission HOME : smoke SSH interactif réussit, sessions launchd non — répertoires config non inscriptibles ou verrous profil sur la mauvaise UID.
4. Blocage modal : sans blockedByDialog, evaluate pend sur bannières cookies ou SSO ; snapshots vides malgré navigate HTTP 200.

Nommez tôt ces clusters dans vos runbooks : binaire Chromium manquant = presque toujours un problème de compte, pas un bug Playwright. Exit 137 après pic charge = parallélisme, pas réseau. Snapshots vides sur URL joignable = modales ou anti-bot — les deux exigent une politique explicite dans la config Skill.

Lors des revues d'incident sur Mac cloud, les équipes suspectent souvent le réseau ou le Provider LLM alors que JSONL montre déjà ENOENT sur les chemins Chromium ou SIGKILL sans stacktrace. Gardez une seule toolCallId pendant l'analyse et ne modifiez pas en parallèle auth passerelle, config Skill et install browser. Avant la mise en production, définissez quelles URLs sont autorisées et quels domaines restent exclus — cela réduit le risque sécurité et la parallélisme inutile due aux boucles retry.

Un cinquième motif, moins documenté : caches Playwright ou Chromium obsolètes après minor upgrade. Symptôme : navigate échoue sporadiquement avec erreurs protocol alors que doctor reste vert. Souvent un purge ciblée du cache browser sous le HOME launchd plus réinstall suffit — toujours même compte, jamais via sudo depuis shell root interactive.

2. Matrice décision : Mac VPS headless vs Mac local vs browser Docker

Les Mac locaux conviennent au debug sélecteurs ; pour 7j/24 avec passerelle sur port 18789 co-localisée, le Mac cloud headless l'emporte. Les stacks browser conteneurisés sont décrits dans le runbook Compose 7j/24.

Les équipes qui exploitent déjà des canaux IM sur Mac VPS ne devraient pas externaliser browser skill sur un hôte Linux séparé tant que sessions login et profils Chromium doivent appartenir à l'utilisateur passerelle. La matrice reste volontairement orientée opérations pour éviter les dérives tooling en revue architecture.

Pour batch courts — snapshots prix nocturnes sans boucle IM interactive — Docker sur le même Mac VPS peut convenir si healthchecks Compose et plafonds ressources sont standardisés. Dès qu'un agent doit naviguer live pendant un fil Telegram, la co-localisation avec la passerelle l'emporte : chaque hop supplémentaire augmente la latence queue et complique la corrélation sessionId, toolCallId et événements canal en JSONL. Les Mac locaux restent imbattables pour debug sélecteurs visuel, mais pas comme point unique production : veille, VPN et clics modaux manuels ne scalent pas en 7j/24 auditable.

3. Prévol Mac VPS : Node 22, 18789 et HOME même compte

Avant d'installer skill-browser, la couche passerelle doit être stable. Les instances OpenClaw à moitié installées produisent de faux positifs sur les smokes browser.

• Runtime : Node.js 22 ou plus ; openclaw doctor et openclaw --version sans alertes demi-install.
• Passerelle : lsof -i :18789 ou openclaw gateway status montre un listener ; sinon suivre le runbook install passerelle.
• Alignement compte : noter UserName et HOME du plist launchd ; install Chromium et config Skill sous le même utilisateur.
• Ressources et audit : 8 Go RAM et 20 Go disque libre recommandés ; avant pull ClawHub compléter audit sécurité Skill.

Capturez echo $HOME en shell SSH interactive et via session simulée launchctl asuser. Toute divergence ici explique le plus souvent « vert en local, rouge en prod » pour browser skill.

Prévoyez au moins vingt pour cent de RAM libre au-dessus du footprint Chromium attendu. Sur nœuds Mac cloud partagés, browser skill, passerelle et modèles embedding locaux concurrencent le même pool mémoire. Si Ollama ou autres providers tournent en parallèle, documentez explicitement que chaque context browser ouvert coûte réalistement quatre cents à six cents Mo. Les IOPS disque sont le second goulot : volume lent allonge cold start et augmente flakiness timeout sur SPA lourdes.

Avant le premier openclaw skills install skill-browser, l'audit ClawHub doit être terminé. Skills tiers avec accès shell ou fichiers élargissent la surface d'attaque sur l'hôte qui détient tokens passerelle et secrets IM. Reprenez les recommandations exec gating de l'article audit Skill et traitez browser skill comme toute extension production : versionnée, revue, rollback-ready.

4. Table paramètres skill-browser : headless, parallèle, timeout

skill-browser repose sur Playwright Chromium headless. Le tableau sert de squelette revue — après chaque upgrade recroisez avec openclaw doctor sur la config live.

Le parallélisme est le levier principal de stabilité : un seul contexte suffit à la plupart des flux déclenchés par IM. N'augmentez parallel contexts que si le RSS reste sous 60 % de la RAM disponible et le taux snapshot stable au-dessus de 95 %.

Pour blockedByDialog, deux stratégies production : dismiss pour bannières cookies marketing qui ne doivent pas bloquer le flux, et fail-fast pour modales SSO ou paiement où agent pendu est pire qu'erreur claire à l'utilisateur. Documentez le choix par domaine cible dans le runbook. Pour timeout-ms, modèle bi-niveau : defaults bas pour outils internes DOM stable, valeurs hautes pour pages externes JS lourd — sans bloquer la file outils sous charge.

5. Runbook sept étapes : compte → install → Chromium → sonde → smoke → launchd

1. Aligner compte et HOME : vérifier UserName du plist launchd ; SSH sous le même utilisateur ; echo $HOME doit correspondre au plist.
2. Épingler version et doctor : sauvegarder openclaw.json, exécuter openclaw doctor ; upgrades selon runbook release train mai.
3. Installer skill-browser : après audit openclaw skills install skill-browser.
4. Installer Chromium : même compte npx puppeteer browsers install chromium ; noter le chemin dans les journaux.
5. Écrire paramètres : headless, parallel contexts, timeout-ms, blockedByDialog dans config Skill.
6. Sonde et smoke : confirmer port 18789 ; URL fixe pour snapshot ; archiver toolCallId en JSONL.
7. Acceptation launchd : charger plist, simuler redémarrage, répéter smoke — résultat identique requis.

Archivez sorties snapshot et lignes JSONL associées dans le ticket de changement. Les responders verront ainsi les régressions post-upgrade en diff sans redéboguer toute la pile.

L'étape deux — épinglage version — mérite attention sur branche 2026.5 : chargement Skill et exec gating se sont durcis. Après upgrade, déclenchez un flux E2E minimal : message IM → agent appelle browser tool → snapshot retour. Comparez defaults headless et blockedByDialog à l'état pré-upgrade ; drift ici explique nombreux evaluate pendus « aléatoires ». L'étape sept — acceptation launchd — n'est pas optionnelle : smoke SSH interactive ne prouve rien sur durée de vie après reboot ou reload plist.

6. Trois signaux : cold start, RSS, taux snapshot

• Cold start Chromium : premier lancement sur Mac cloud sous huit secondes ; au-delà de quinze secondes de façon durable = goulot disque ou politique warmup absente.
• Utilisation mémoire : après smoke single-context, passerelle plus Chromium sous 60 % RAM disponible.
• Taux snapshot : vingt répétitions même URL ≥ 95 % succès ; sous 90 % ajuster d'abord politique modale, pas parallélisme.

Liez ces trois KPI au paging existant : régression cold start post-deploy = Chromium manquant ou mauvais cache ; pics RSS = parallel contexts ; dérive snapshot = anti-bot ou changement SSO sur la cible.

Ajoutez si possible un tableau de bord simple : taux snapshot par heure, p95 cold start et RSS passerelle après browser tool. Seuils verbatim dans le runbook — « sous 90 % snapshot sur 15 minutes » mérite pager ; « timeout isolé » souvent non. Plusieurs URLs cibles : baseline par URL, car politique anti-bot varie fortement par domaine.

7. Table erreurs et triage par couche

« Outil browser échoué » : Chromium présent → HOME même compte → headless/parallèle → modales/timeouts. Chaque couche rattachée au toolCallId JSONL.

Évitez de modifier en parallèle auth passerelle, config Skill et install Chromium pendant un incident. Une chaîne toolCallId stable accélère les post-mortems mieux que des captures shell interactif.

Couche un — Chromium présent — vérifiez sous le même user que launchd : which chromium seul ne suffit pas si puppeteer a installé dans cache user-specific. Couche deux — HOME — comparez plist, shell interactive et environnement launchd simulé. Couche trois — paramètres — validez headless true sur hôte sans bureau et parallel contexts vs budget RAM. Couche quatre — modales et réseau — blockedByDialog, timeout et éventuel changement URL. N'analysez DOM ou anti-bot cible qu'après couches un à trois vertes.

8. Cas métier : formulaires, monitoring et IM

Automatisation formulaire support : un agent reçoit tickets via Telegram, ouvre formulaire interne avec skill-browser, remplit champs et renvoie capture ; modales SSO en fail-fast pour éviter boucles infinies.

Monitoring concurrent : cron déclenche snapshots sélecteurs fixes en JSONL ; parallel contexts reste à 1 contre OOM ; dérive DOM détectée par comparaison snapshots.

Naviguer puis répondre : utilisateurs interrogent @bot sur doc ; agent navigue d'abord vers doc live puis résume — idéal pour pages login ou rendu client-side que seule la LLM sans URL fausserait.

Captures conformité : audits réglementaires ou internes exigent preuves périodiques qu'une page statut publique contient certains textes. Flux cron avec sélecteur fixe et snapshot archivé en JSONL fournit preuve reproductible — si parallel contexts reste conservateur et URL cible en allowlist. Ne combinez pas ces jobs avec pics IM interactifs sur même nœud sans réserve RAM.

9. FAQ

Question : skill-browser coexiste avec Ollama ou plusieurs providers ? Oui ; sous-processus browser découplés. Fixez plafond concurrence dans tools.profile et observez RSS dans gateway status --deep.

Question : Réaccepter après upgrade v2026.5.x ? doctor, réinstaller Chromium même compte, smoke snapshot minimal — voir runbook release train.

Question : Mac cloud vs VPS Linux ou Docker ? 7j/24 passerelle co-localisée : Mac cloud ; batch courts : Docker possible mais triage OOM et droits plus long.

10. Conclusion

Critère succès : skill-browser → Chromium même compte → snapshot reproductible via port 18789. Portable et WSL2 tiennent rarement 7j/24 ; browser Docker sur VPS Linux lutte avec /dev/shm et détection headless. Pour browser skill en parallèle des canaux IM en continu, louer un nœud Mac cloud Apple Silicon VPSMAC regroupe passerelle, cache Chromium et launchd dans un runbook unique. Docker reste pertinent pour batch courts, sans remplacer la pile Mac headless production. Suite : Docker 7j/24 et audit Skill.