El relay de navegador de OpenClaw

Tu agente puede descargar una página, pero descargarla no es lo mismo que usarla. La pestaña que importa ya tiene la sesión iniciada, está en una computadora portátil en otra habitación, y el Gateway se ejecuta en un servidor en un lugar completamente distinto. La respuesta de OpenClaw es retransmitir las acciones del navegador a la máquina donde realmente vive el navegador, y mantenerlas allí.

Cuatro lugares donde puede vivir el navegador

• Control local, el predeterminado. El Gateway inicia el servicio de control en loopback y puede lanzar un navegador local. Las acciones sin destino, como open, navigate u openclaw browser start, pueden lanzarlo; una acción que nombra una pestaña por targetId, id de pestaña o etiqueta nunca inicia un navegador detenido, porque un navegador nuevo no puede contener esa pestaña.
• Control remoto a través de un node host. Ejecutas un node host en la máquina que tiene el navegador, y el Gateway le reenvía las acciones del navegador. El nodo expone su propio servidor local de control del navegador mediante un comando proxy, así que el Gateway nunca necesita el binario del navegador.
• CDP remoto. Define la clave cdpUrl bajo tu perfil en browser.profiles, o el antiguo browser.cdpUrl de perfil único, para conectarte a un navegador remoto basado en Chromium. En ese caso, OpenClaw no lanzará ningún navegador local propio.
• Servicios loopback de solo conexión. Para un servicio CDP gestionado externamente y publicado en 127.0.0.1 (Browserless en Docker es el caso habitual), define también attachOnly: true. Un CDP en loopback sin attachOnly se trata como un perfil local gestionado por OpenClaw, y OpenClaw puede informar de que el puerto está en uso pero no pertenece a OpenClaw.

Una vez que una acción llega al nodo, su instantánea o sus ajustes posteriores se quedan en ese nodo en lugar de cambiar de navegador.

El enrutamiento se decide una vez, no por acción

El enrutamiento automático prefiere el host, incluido un navegador gestionado detenido cuyo ejecutable simplemente está instalado. Un destino explícito node, un selector de nodo o gateway.nodes.browser.node sobrescriben esa preferencia, mientras que target=host siempre se queda en el host. El propietario que se seleccione se queda después con todo: las conexiones existing-session, extension, de solo conexión y de CDP remoto le pertenecen aunque no haya un ejecutable de navegador gestionado, y los fallos de lanzamiento, los ajustes de ejecutable no válidos, los errores de permisos y los fallos de acciones en la página se quedan en ese propietario en lugar de repetirse en otra máquina. El respaldo automático al host desde un nodo seleccionado solo se permite antes de que ese nodo haya atendido una solicitud, que es la frase anterior llevada a la práctica. Esto es lo que hace coherente una tarea de navegador de varios pasos: la instantánea sobre la que actúas y las referencias de elementos que devolvió describen un navegador, no dos.

Los límites que mantiene el relay

• Los perfiles salen de la propia configuración browser.profiles del nodo, exactamente como si estuvieras sentado frente a esa máquina. El Gateway no proyecta su propia lista de perfiles sobre el nodo.
• Las modificaciones persistentes de perfiles se rechazan a través del comando proxy, sin importar cómo esté configurado: create-profile, delete-profile y reset-profile están bloqueados independientemente de allowProfiles. Haz esos cambios directamente en el nodo.
• nodeHost.browserProxy.allowProfiles es opcional. Si se deja vacío, todos los perfiles configurados siguen siendo accesibles a través del proxy, que es el comportamiento predeterminado heredado. Si lo defines, OpenClaw lo trata como un límite de mínimo privilegio que restringe a qué nombres de perfil puede apuntar el proxy. Para desactivar toda la vía, usa nodeHost.browserProxy.enabled=false en el nodo, o gateway.nodes.browser.mode=off en el Gateway, que también acepta auto y manual.

El agente ve una sola herramienta para las cuatro configuraciones: una única herramienta browser que cubre doctor, status, start, stop, tabs, open, focus, close, snapshot, screenshot, navigate, act, requests, errors, text y emulate, con un argumento profile para indicar qué navegador y un argumento target con sandbox, host o node para indicar qué máquina. El mismo verbo puede significar cosas distintas según el modo. Stop en un perfil local gestionado termina el proceso que lanzó OpenClaw, mientras que en los perfiles de solo conexión y de CDP remoto cierra la sesión de control activa y libera las sobrescrituras de emulación de Playwright y CDP para el viewport, el esquema de color, la configuración regional, la zona horaria y el modo sin conexión, aunque OpenClaw nunca lanzó allí un proceso de navegador. El ajuste headless sigue la misma regla, ya que solo afecta a los perfiles locales gestionados que lanza OpenClaw. La lista completa de acciones y sus argumentos está en las acciones de la herramienta browser, y qué es realmente un node host, cómo se empareja y qué más puede llevar, está en los nodos de navegador.

Navegadores alojados y las tres formas de URL

OpenClaw acepta tres formas de URL de CDP y elige automáticamente la estrategia de conexión para cada una. Una base http:// o https:// significa descubrimiento: OpenClaw llama a /json/version, lee la URL del depurador WebSocket y se conecta, sin respaldo WebSocket. Un endpoint ws:// o wss:// directo con una ruta /devtools/browser, page, worker, shared_worker o service_worker omite por completo /json/version. Una raíz WebSocket sin más, sin ruta /devtools, que es lo que te dan Browserless y Browserbase, intenta primero el descubrimiento HTTP y recurre a un handshake directo en la raíz si el descubrimiento no devuelve nada utilizable. Esas URL suelen llevar la autorización como un token en la query o como credenciales HTTP Basic, y OpenClaw conserva esa autenticación tanto al llamar a los endpoints /json/* como al abrir el WebSocket de CDP, así que trata la URL completa como un secreto y guárdala en una variable de entorno o en un gestor de secretos en lugar de en un archivo de configuración. Los diagnósticos usan la misma lógica de descubrimiento primero y respaldo WebSocket después que una conexión en tiempo de ejecución, así que la API de control del navegador no informa como inaccesible una raíz sin más que sí conecta. El único modo de navegador con sesión iniciada que no tiene ningún cdpUrl es el relay de la extensión de Chrome, cuyo relay posee su endpoint loopback y controla pestañas reales sin nadie frente a la computadora.

En Diali

Diali aloja OpenClaw como servicio gestionado. Cada cliente obtiene su propio asistente en su propio runtime en lugar de un puesto en un pool compartido. La configuración del runtime se genera desde tu panel y se vuelve a escribir en cada versión, así que el bloque browser que defines en la interfaz es con el que arranca el agente. Todo lo que el agente conserva está en un volumen persistente, con instantáneas diarias y restauración con un clic disponibles con el complemento Copias de seguridad (incluido en Max). OpenClaw alojado en Diali describe el runtime alojado, y la página de precios de Diali recoge los planes.

• Un node host retransmite las acciones del navegador a la máquina que posee el navegador.
• Una vez que una acción llega a un nodo, el resto de la tarea se queda allí.
• attachOnly evita que un servicio CDP en loopback se confunda con un perfil gestionado.