La Control UI de OpenClaw

Instalaste OpenClaw, iniciaste el Gateway y leíste en algún sitio que hay un panel en el navegador. Abrirlo es cuestión de una URL, pero la página que carga pide un Gateway secret que nadie te ha dado, y puede que la dirección LAN impresa en la terminal ni siquiera responda desde tu computadora portátil. Esto es lo que es realmente la Control UI, lo que acepta ese único campo y lo que hace el listado que hay detrás.

Qué sirve el Gateway en el puerto 18789

• La Control UI es una pequeña aplicación de una sola página hecha con Vite y Lit que sirve el propio Gateway, en http://your-host:18789/ por defecto, con un prefijo opcional cuando defines gateway.controlUi.basePath, por ejemplo /openclaw. Habla directamente con el WebSocket del Gateway en el mismo puerto, así que no hay un segundo servicio que iniciar ni un host de API aparte al que apuntarla.
• En el host del Gateway, abre http://127.0.0.1:18789/ o http://localhost:18789/. Si la página no carga en absoluto, inicia primero el Gateway con openclaw gateway.
• gateway.controlUi.enabled se aplica en caliente. Desactívalo y el Gateway deja de servir las páginas y los recursos del panel mientras los bots y las conexiones existentes al Gateway siguen funcionando; vuelve a activarlo y el servicio se reanuda, con los recursos que falten preparados en segundo plano. Cambiar la ruta base desde la que se sirve o la raíz de los recursos sigue requiriendo reiniciar el Gateway.
• Si la URL de la LAN funciona en el host pero no desde otra máquina, sospecha del host antes que de la red. Cuando el Gateway se enlaza a la LAN en Windows nativo, el Firewall de Windows o una directiva de grupo (Group Policy) gestionada por la organización puede bloquear la URL de LAN anunciada aunque 127.0.0.1 funcione en el host del Gateway, y openclaw gateway status --deep, ejecutado en ese host Windows, informa de los puertos probablemente bloqueados, los perfiles que no coinciden y las reglas de firewall locales que la directiva puede ignorar.

Una conexión directa por loopback no se salta la autenticación por token o contraseña.

Por qué la página en tu propia máquina sigue pidiendo un secreto

La autenticación ocurre durante el handshake de WebSocket, no en un formulario de inicio de sesión que la aplicación pudiera saltarse discretamente para los visitantes locales. El Gateway acepta el secreto compartido configurado en connect.params.auth.token o en connect.params.auth.password, y gateway.auth.mode selecciona qué valor configurado se aplica; también acepta las cabeceras de identidad de Tailscale Serve cuando gateway.auth.allowTailscale es true, y las cabeceras de identidad de proxy de confianza cuando gateway.auth.mode es trusted-proxy. La autenticación del Gateway se ejecuta antes del emparejamiento de dispositivos, así que un navegador demuestra quién es con el secreto compartido antes incluso de poder presentar una solicitud de emparejamiento. Un navegador en loopback directo no necesita secreto compartido solo cuando gateway.auth.mode se establece explícitamente en none, lo que desactiva por completo la autenticación del Gateway y no es la configuración recomendada para la Control UI.

Un campo, dos tipos de valor

• La pantalla de inicio de sesión y Settings, luego Gateway, usan el mismo campo único Gateway secret: pega el token o escribe la contraseña. El navegador no elige el modo; gateway.auth.mode ya lo eligió en el host.
• Tras una conexión correcta, la interfaz guarda el secreto en el almacenamiento de sesión, limitado a la pestaña actual del navegador y al origen del Gateway, y solo cuando el Gateway indica autenticación por token. Las contraseñas se quedan en memoria y nunca se persisten, y una vez emparejado el dispositivo, el navegador puede usar el token por dispositivo que tiene almacenado en las conexiones posteriores.
• Un código de configuración copiado desde Devices, Pair device, Copy setup code es una credencial distinta. Si pegas uno en Gateway secret, la interfaz muestra un aviso en línea antes de conectar: ese código va en Settings, luego Gateway, de la aplicación móvil de OpenClaw, mientras que la Control UI espera el token compartido que devuelve openclaw gateway auth-token --show, ejecutado en una terminal interactiva en el host del Gateway.

Hay un estado que parece un error y no lo es. La configuración inicial local genera por defecto un Gateway secret en modo token, sin selector entre token y contraseña, y conserva un modo de contraseña existente; para configurar explícitamente una contraseña se usa --gateway-auth password o --gateway-password con el valor que elijas, y Tailscale Funnel requiere el modo contraseña. Pero si el Gateway arranca en modo token sin token configurado, genera en su lugar un token de ejecución efímero para ese proceso. Ese token no se escribe en la configuración, así que no se puede recuperar, y un navegador en loopback que no lo tenga es rechazado: el campo que tienes delante pide un valor que no existe en ningún lugar donde puedas leerlo. La solución es ejecutar openclaw doctor --generate-gateway-token, reiniciar el Gateway y luego ejecutar openclaw gateway auth-token --show en una terminal interactiva y pegar el resultado en Gateway secret; el doctor de OpenClaw detalla qué más puede tocar esa herramienta de reparación, y la explicación del Gateway describe el proceso al que pertenece el puerto para empezar.

El listado de agentes y el modo equipo

Abre Agents en la barra lateral, elige All agents en el selector de agentes o visita /agents, y obtendrás un listado en lugar de un chat: una tarjeta por agente configurado con su identidad, su modelo, su estado de trabajo actual, su última actividad y una vista previa de su chat principal, con los agentes que están trabajando primero y los más recientemente activos detrás. Open chat salta a la sesión principal de ese agente, Manage agents abre /settings/agents y New agent abre el chat del custodian, que recomienda un jefe de gabinete, un investigador, un redactor, un revisor o un pequeño equipo con los cuatro, usando las mismas plantillas de rol que la CLI y esperando la aprobación del operador antes de crear nada. Elegir Show all agents activa el modo equipo: las sesiones se reagrupan bajo encabezados de agente plegables en el orden configurado del listado, la fila superior se convierte en un encabezado de espacio de trabajo con el nombre visible configurado del Gateway, y el ámbito de página compartido pasa por defecto a All agents, de modo que Automations, Dashboards, Sessions, Tasks y Usage muestran filas de varios agentes con la identidad del agente adjunta. El modo equipo es una preferencia del navegador, desactivada por defecto y recordada por Gateway en ese navegador, así que el mismo Gateway abierto desde otro perfil o mediante el acceso remoto a OpenClaw empieza en modo de un solo agente hasta que lo actives allí. Cómo acaban varios agentes aislados dentro de un único proceso de Gateway es un tema aparte, que se trata en el artículo sobre varios agentes en un solo Gateway.

En Diali

Diali aloja OpenClaw, así que el puerto, el token y el certificado dejan de ser tu problema: cada cliente ejecuta su propio asistente en su propia instancia, y servimos la Control UI por HTTPS en una dirección real en lugar de en una URL de LAN en texto plano. La configuración de ejecución se genera desde tu panel de Diali y se reescribe en cada versión, así que lo que se ejecuta siempre coincide con lo que seleccionaste, y el estado del agente vive en un volumen persistente, con instantáneas diarias y restauración en un clic disponibles mediante el complemento Copias de seguridad (incluido en Max). OpenClaw alojado en Diali describe lo que incluye el asistente alojado, y la página de precios de Diali enumera los planes.

• El panel es el propio Gateway, en un solo puerto.
• Un navegador en loopback sigue necesitando el secreto configurado.
• Un token de ejecución efímero nunca se puede volver a leer.