Le relais navigateur OpenClaw

Votre agent sait récupérer une page, mais récupérer n’est pas utiliser. L’onglet qui compte est déjà connecté, il se trouve sur un portable dans une autre pièce, et la Gateway tourne sur un serveur ailleurs. La réponse d’OpenClaw consiste à relayer les actions du navigateur vers la machine où le navigateur vit vraiment, puis à les y maintenir.

Quatre endroits où le navigateur peut vivre

• Le contrôle local, par défaut. La Gateway démarre le service de contrôle en loopback et peut lancer un navigateur local. Les actions sans cible comme open, navigate ou openclaw browser start peuvent le lancer ; une action qui nomme un onglet par targetId, identifiant d’onglet ou libellé ne démarre jamais un navigateur arrêté, car un navigateur neuf ne peut pas contenir cet onglet.
• Le contrôle distant via un node host. Vous faites tourner un node host sur la machine qui possède le navigateur, et la Gateway lui relaie les actions. Le nœud expose son propre serveur de contrôle local du navigateur via une commande proxy, si bien que la Gateway n’a besoin d’aucun binaire de navigateur.
• Le CDP distant. Renseignez la clé cdpUrl sous votre profil dans browser.profiles, ou l’ancien browser.cdpUrl mono-profil, pour vous attacher à un navigateur Chromium distant. Dans ce cas, OpenClaw ne lance aucun navigateur local.
• Les services en attache seule. Pour un service CDP géré à l’extérieur et publié sur 127.0.0.1, Browserless dans Docker étant le cas courant, ajoutez aussi attachOnly: true. Un CDP en loopback sans attachOnly est traité comme un profil local géré par OpenClaw, et OpenClaw peut signaler que le port est occupé mais n’appartient pas à lui.

Une fois qu’une action atteint le nœud, son instantané de suivi ou ses réglages restent sur ce nœud au lieu de changer de navigateur.

Le routage se décide une fois, pas à chaque action

Le routage automatique préfère l’hôte, y compris un navigateur géré à l’arrêt dont l’exécutable est simplement installé. Une cible node explicite, un sélecteur de nœud ou gateway.nodes.browser.node l’emporte sur cette préférence, tandis que target=host reste toujours sur l’hôte. Le propriétaire retenu garde ensuite tout : les connexions existing-session, extension, attache seule et CDP distant lui appartiennent même sans exécutable de navigateur géré, et les échecs de lancement, les réglages d’exécutable invalides, les erreurs de permission et les échecs d’action de page restent chez lui au lieu d’être rejoués sur une autre machine. Le repli automatique vers l’hôte depuis un nœud sélectionné n’est autorisé qu’avant que ce nœud ait traité une requête, ce qui est la phrase ci-dessus en pratique. C’est ce qui rend cohérente une tâche de navigateur en plusieurs étapes : l’instantané sur lequel vous agissez et les refs d’éléments qu’il a renvoyées décrivent un seul navigateur, pas deux.

Les limites que le relais maintient

• Les profils viennent de la config browser.profiles du nœud lui-même, exactement comme si vous étiez assis devant cette machine. La Gateway ne projette pas sa propre liste de profils sur le nœud.
• Les modifications persistantes de profil sont refusées par la commande proxy quelle que soit la configuration : create-profile, delete-profile et reset-profile sont bloquées indépendamment de allowProfiles. Faites ces changements directement sur le nœud.
• nodeHost.browserProxy.allowProfiles est facultatif. Laissé vide, tous les profils configurés restent joignables via le proxy, ce qui correspond au comportement historique par défaut. Renseigné, OpenClaw le traite comme une frontière de moindre privilège qui limite les noms de profils que le proxy peut viser. Pour couper le chemin entier, utilisez nodeHost.browserProxy.enabled=false sur le nœud, ou gateway.nodes.browser.mode=off sur la Gateway, qui accepte aussi auto et manual.

L’agent ne voit qu’un seul outil pour ces quatre montages : un outil browser unique qui couvre doctor, status, start, stop, tabs, open, focus, close, snapshot, screenshot, navigate, act, requests, errors, text et emulate, avec un argument profile pour choisir le navigateur et un argument target valant sandbox, host ou node pour choisir la machine. Le même verbe peut signifier des choses différentes selon le mode. Stop sur un profil local géré termine le processus lancé par OpenClaw, alors que sur les profils en attache seule et en CDP distant il ferme la session de contrôle active et libère les surcharges d’émulation Playwright et CDP sur la fenêtre, le thème clair ou sombre, la locale, le fuseau horaire et le mode hors ligne, même si OpenClaw n’y a jamais lancé de processus. Le réglage headless suit la même règle, puisqu’il ne concerne que les profils locaux gérés qu’OpenClaw lance. La liste complète des actions et de leurs arguments est dans les actions de l’outil browser, et ce qu’est réellement un node host, comment il s’appaire et ce qu’il peut porter d’autre, est dans les nœuds navigateur.

Navigateurs hébergés et les trois formes d’URL

OpenClaw accepte trois formes d’URL CDP et choisit automatiquement la stratégie de connexion pour chacune. Une base http:// ou https:// signifie découverte : OpenClaw appelle /json/version, lit l’URL WebSocket de débogage et se connecte, sans repli WebSocket. Un point de terminaison ws:// ou wss:// direct avec un chemin /devtools/browser, page, worker, shared_worker ou service_worker ignore complètement /json/version. Une racine WebSocket nue sans chemin /devtools, ce que vous donnent Browserless et Browserbase, tente d’abord la découverte HTTP puis se rabat sur une poignée de main directe à la racine si la découverte ne renvoie rien d’exploitable. Ces URL portent souvent l’autorisation sous forme de jeton en requête ou d’identifiants HTTP Basic, et OpenClaw conserve cette authentification aussi bien pour les appels aux points /json/* que pour l’ouverture du WebSocket CDP : traitez donc l’URL entière comme un secret et gardez-la dans une variable d’environnement ou un gestionnaire de secrets plutôt que dans un fichier de configuration. Le diagnostic utilise la même logique de découverte d’abord puis repli WebSocket que l’attache à l’exécution, donc une racine nue qui se connecte n’est pas signalée comme injoignable par l’API de contrôle du navigateur. Le seul mode de navigateur déjà connecté qui n’a aucun cdpUrl est le relais de l’extension Chrome, dont le relais possède son point de terminaison loopback et pilote de vrais onglets sans personne devant l’ordinateur.

Sur Diali

Diali héberge OpenClaw en service géré. Chaque client obtient son propre assistant sur son propre runtime, et non une place dans un pool partagé. La configuration du runtime est générée depuis votre tableau de bord et réécrite à chaque version, si bien que le bloc browser défini dans l’interface est celui avec lequel l’agent démarre. Tout ce que l’agent conserve repose sur un volume persistant, avec des instantanés quotidiens et une restauration en un clic grâce à l’option Sauvegardes (incluse avec Max). OpenClaw hébergé sur Diali décrit le runtime hébergé, et Tarifs Diali présente les offres.

• Un node host relaie les actions vers la machine qui possède le navigateur.
• Dès qu’une action atterrit sur un nœud, la suite de la tâche y reste.
• attachOnly évite qu’un service CDP loopback passe pour un profil géré.