budget-tracker/memory/2026-02-27-chrome-wrapper.md

Session: 2026-02-27 11:05:40 UTC

• Session Key: agent:main:main
• Session ID: e75bc5d4-fd05-4ad6-afc4-eea608d0ffd5
• Source: telegram

Conversation Summary

assistant: Je cherche d'abord comment le conteneur démarre pour choisir la bonne méthode : assistant: Je comprends l'architecture complète. Voici le plan le plus propre :

1. Créer un script de démarrage Chrome dans le workspace (persistant) 2. Corriger oc-up.sh avec le bon binaire et le bon chemin 3. Configurer OpenClaw en attachOnly: true 4. Ajouter une sécurité via le docker-compose override assistant: Solution trouvée ! Je vais créer un wrapper pour le binaire Chrome — OpenClaw appelle executablePath pour lancer Chrome, donc je mets un wrapper qui nettoie les locks avant de lancer le vrai Chrome. Transparent, permanent, aucune modification du système : assistant: Maintenant je mets à jour la config OpenClaw pour pointer vers le wrapper : assistant: Testons que ça fonctionne — je simule un redémarrage (kill Chrome + ajout de faux locks) : assistant: Le wrapper fonctionne — il a nettoyé les anciens locks et Chrome a démarré proprement. Maintenant, je corrige aussi oc-up.sh qui utilisait un mauvais chemin : assistant: Maintenant vérifions que le browser tool OpenClaw fonctionne bien avec la config mise à jour : assistant: Le browser répond. Maintenant mettons à jour MEMORY.md avec ce fix pour que je m'en souvienne : assistant: Tout est en place. Voici le résumé de ce qui a été fait :

---

Diagnostic : après chaque redémarrage du conteneur, Chrome laisse des fichiers SingletonLock, SingletonCookie, SingletonSocket dans son profil persistant. Au redémarrage suivant, Chrome refusait de démarrer à cause de ces locks résiduels → timeout du browser tool.

Fix permanent : un wrapper chrome-wrapper.sh (dans le workspace, donc persistant) qui :

1. Supprime les lock files résiduels
2. Lance le vrai Chrome normalement

OpenClaw est maintenant configuré pour appeler ce wrapper via browser.executablePath. Peu importe combien de fois le conteneur redémarre, Chrome se lancera proprement à la première utilisation du browser tool.

Bonus : start-chrome-cdp.sh dans le workspace si jamais tu as besoin de le relancer manuellement. user: Conversation info (untrusted metadata):

{
  "message_id": "1027",
  "sender_id": "2037871620",
  "sender": "2037871620"
}

Refait le test sur le site de www.bordeauxcognactourguide.com assistant: 1b7006b1-aeb1-48e4-a273-6157f7dbeea6.jpg assistant: NO_REPLY user: Conversation info (untrusted metadata):

{
  "message_id": "1031",
  "sender_id": "2037871620",
  "sender": "2037871620"
}

Retiens ce que tu as fait pour la prochaine fois si jamais ça bug assistant: C'est déjà dans MEMORY.md et commité, mais je vais aussi enrichir le détail pour être sûr d'avoir tout en cas de bug futur : assistant: C'est maintenant dans les deux endroits :

• MEMORY.md (commité) — je le relis à chaque session, donc je saurai immédiatement quoi faire
• Mémoire vectorielle Qdrant — si je cherche "browser ne fonctionne pas" ou "SingletonLock", je retrouverai le diagnostic complet et les commandes exactes

La prochaine fois que ça bug, je saurai en 10 secondes que c'est le lock file et comment régler ça. 🌑