Mira trabajar a tu bot — y toma el ratón cuando se tope con un login


Tu bot se queda atascado a las 3 de la mañana en el portal de un proveedor que pide iniciar sesión. Te lo dice en el chat y termina su turno, y a partir de ahí todo son conjeturas: en qué página se paró, si destrozó el formulario que había enviado un minuto antes. Para cuando te pones con ello la session ya se ha enfriado, y puede que mientras tanto haya hecho clic en otra cosa. Bot Screen existe precisamente para eliminar esas conjeturas. En un host Linux headless, cada profile tiene ahora su propio escritorio, retransmitido en directo a Hermes Desktop. Puedes ver trabajar al bot, tomar el control del teclado y el ratón cuando te necesite, y después devolvérselo para que continúe.

Qué es en realidad

En una frase: cada bot tiene su propio escritorio Xfce, ejecutándose en el host del gateway.

  • El computer_use del bot (automatización de escritorio) y su navegador con interfaz (browser.headed: true) actúan sobre esa pantalla.
  • La pantalla se retransmite a un panel dentro de Hermes Desktop a través de noVNC.
  • Cada profile tiene su propia pantalla, su propio perfil de navegador y sus propias cookies.
  • Lo importante: la pantalla vive en el host del gateway, no en tu portátil. Cierra la app, baja la tapa: el bot sigue trabajando en el servidor.

Esa es la diferencia con «escritorio remoto hacia mi propia máquina»: el agente se ejecuta en el servidor, el escritorio se ejecuta en el servidor, y tu cliente no es más que una ventana hacia él.

Para qué lo usas: logins, 2FA, CAPTCHAs, pagos

El bot no debería hacer estos pasos por su cuenta, y tampoco debería bloquearse esperándote:

  1. Se topa con un paso de login, 2FA, CAPTCHA o pago, te lo dice en su respuesta y termina su turno.
  2. La petición te llega al chat en el que estés — Telegram, Slack, Desktop.
  3. Cuando tengas un hueco, abre el panel y haz clic en Take over. El borde se pone rojo; tu teclado y tu ratón pasan a controlarlo.
  4. Inicia sesión, resuelve el CAPTCHA, aprueba el pago.
  5. Haz clic en Hand back. El bot recupera el control y vuelve a capturar la pantalla antes de continuar.

Merece la pena fijarse en dos detalles. Un bot nunca mantiene una tool call abierta esperándote — tomar el control siempre lo inicias tú. Y cuando dos visores se pelean por una misma pantalla, gana el Take over más reciente; el controlador anterior vuelve a modo observador. «Hand back» y «conexión caída» también son cosas distintas: si cierras la tapa o se cae el Wi-Fi mientras tienes el control, lo conservas — el bot se queda fuera de una pantalla en la que quizá estés a mitad de un login — hasta que te reconectes y lo devuelvas. Si tras un recargado el panel afirma que un humano sigue teniendo el control, aparece un botón Hand back (force).

Primeros pasos

Requisito: el host del gateway ejecuta Linux. Los hosts macOS y Windows ya tienen una pantalla real, y ahí el panel no se ofrece.

Los paquetes de escritorio (el Xvnc de TigerVNC más el núcleo de Xfce) nunca se instalan en silencio — hermes update y las instalaciones nuevas dejan la máquina tal y como está. Cuando faltan, el panel de Desktop muestra Install on host: un clic ejecuta el gestor de paquetes en ese host y pide la contraseña sudo de ese host en una tarjeta enmascarada (la contraseña solo va a ese host y nunca se guarda).

La imagen Docker oficial — la misma que mueve Hermes Cloud — es el otro caso: el gateway se ejecuta como usuario sin privilegios y la imagen no tiene sudo, así que el panel imprime la línea exacta y un operador la ejecuta una vez como root dentro del contenedor:

docker exec -u 0 <container> apt-get install -y \
  tigervnc-standalone-server xfce4-panel xfwm4 xfdesktop4 xfce4-settings \
  xfce4-terminal dbus-x11 x11-xserver-utils x11-utils xauth fonts-dejavu-core

Las mismas operaciones desde un shell:

hermes computer-use screen status     # ¿instalado? ¿en marcha? ¿quién tiene el control?
hermes computer-use screen start      # arranca la pantalla de este profile
hermes computer-use screen stop       # se niega mientras un humano tenga el control
hermes computer-use screen stop --force   # lo fuerza y limpia un lease atascado
hermes computer-use screen install [-y]   # ejecuta apt/dnf/pacman
hermes -p research computer-use screen start   # la pantalla de otro profile

La pantalla está desactivada por defecto y nada la arranca por ti. bot_desktop.auto_start es false; actívalo y un host headless levanta su pantalla en la primera llamada del bot a computer_use o en el primer uso de un navegador con interfaz. El valor por defecto es deliberado: instalar TigerVNC por motivos que no tienen nada que ver no debería hacer aparecer una pantalla que nadie ha pedido.

bot_desktop:
  geometry: "1440x900"      # tamaño de pantalla; el visor escala para encajar en el panel
  auto_start: false         # true = arrancar en el primer computer_use / navegador con interfaz
  min_free_memory_mb: 1536  # se niega a arrancar por debajo de esta memoria libre (0 = no comprobar)
  idle_stop_minutes: 30     # detiene una pantalla sin usar durante este tiempo (0 = mantenerla viva)

Haz primero las cuentas de memoria

El escritorio es barato; el navegador es el gasto. Medido en la imagen oficial:

Elemento Consumo
Gateway en reposo ~300 MB
Xvnc + Xfce ~220 MB
Chromium con interfaz abierto durante un takeover 0,5–1 GB (~550 MB por una sola página)
CPU prácticamente gratis (escritorio inactivo ≈ 0,01 núcleo)
Disco, paquetes en Debian 13 ~930 MB

Presupuesta 1,1–1,5 GB por pantalla abierta con navegador. La recomendación oficial: con 4 GB el escritorio ya corre, y con 8 GB es donde un takeover con navegador se siente cómodo. Antes de arrancar, Hermes comprueba que el host — o el cgroup de su contenedor, el que sea más ajustado — tenga libres los min_free_memory_mb; por debajo de eso se niega y lo dice en el panel, y una pantalla que ya está en marcha nunca se cae por esta comprobación. Las pantallas inactivas se detienen tras idle_stop_minutes (30 por defecto) y vuelven en el siguiente uso.

Novedad desde el 2026-09-23: dos variantes de imagen

Un despliegue gestionado (Fly Machines, instancias de contenedor de Azure) no puede instalar nada en tiempo de ejecución, así que los paquetes tienen que venir ya construidos dentro. Ahora CI publica dos variantes de cada versión:

  • los tags sin sufijo (:latest, :v*) — sin los paquetes;
  • los tags -desktop (:latest-desktop, :v*-desktop) — con TigerVNC, los componentes de Xfce y el Chromium de la distro.

Tira del tag con sufijo en una instancia gestionada y Bot Screen ya está ahí. La advertencia de hoy, dicha sin rodeos en la documentación: todavía nada en el provisioner selecciona -desktop, así que una instancia gestionada sigue arrancando en versión slim — tirar tú del tag con sufijo sí funciona. Construir tu propia imagen también es opt-in; el argumento de build oficial está desactivado por defecto para que un docker build . normal siga siendo ligero:

docker build --build-arg HERMES_BOT_DESKTOP=1 -t hermes-agent:screen .

Un día después (2026-09-24) aterrizó un cambio complementario: todas las imágenes, incluidos los tags slim sin escritorio, llevan ahora la build completa de Chromium en lugar del headless shell más ligero de Playwright — un único navegador fijado y verificado por checksum sirve tanto para el browsing headless como para las sesiones de Bot Screen con interfaz, a cambio de una imagen más grande.

Las sesiones de navegador sobreviven al traspaso

Esto es lo más práctico de Bot Screen: la tool de navegador del bot y el icono Browser del panel son el mismo navegador. Cada bot lleva un único directorio de datos de usuario persistente (<HERMES_HOME>/bot-desktop/browser-profile), así que durante un takeover estás en las ventanas y en el tarro de cookies del propio bot — y eso con lo que inicias sesión es lo que el bot usará después, en esta ejecución y en todas las siguientes, hasta que el sitio caduque el login.

Activa browser.headed: true si además quieres que la navegación del propio bot se vea en la pantalla. Ten en cuenta que el dock se siembra una sola vez, en el primer arranque de pantalla de un profile: la guarda es el archivo de layout del panel <HERMES_HOME>/bot-desktop/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml. Mientras exista, cambiar AGENT_BROWSER_EXECUTABLE_PATH o AGENT_BROWSER_PROFILE y reiniciar no vuelve a fijar el icono Browser — borra ese archivo y el dock se reconstruye en el siguiente screen start.

La frontera de seguridad: una superficie de trabajo, no un sandbox

La documentación lo dice sin rodeos, y merece la pena repetirlo con el mismo espíritu: el socket RFB de la pantalla, el display X, el perfil de navegador y el archivo de control-lease pertenecen todos al usuario del sistema operativo del gateway. Cualquier proceso que corra como ese usuario — otro bot en el mismo host, y la propia tool terminal del bot — puede alcanzarlos directamente, saltándose el panel y el lease. El lease es una valla a nivel de tool sobre computer_use y las tools de navegador, no una valla del sistema operativo.

Hay una frontera más ancha que el usuario del sistema: el puerto de DevTools de Chromium (el Browser del dock y cada arranque de agent-browser anuncian uno en loopback) es alcanzable por cualquier usuario local del host, y Chromium no ofrece ninguna restricción por usuario para ello. Ejecutar cada bot como su propio usuario del sistema queda fuera del alcance; si ese aislamiento te importa, o el host tiene usuarios locales en los que no confías, pon los bots en hosts separados.

Dos detalles de temporización: el puente WebSocket cachea su decisión de lease hasta 250 ms, así que un takeover hecho por otro proceso se aplica dentro de esa ventana. Y el display_ticket de un solo uso y 30 segundos del visor viaja como parámetro de query en la URL a propósito (noVNC no puede negociar subprotocolos de WebSocket), lo que significa que el log de acceso de un reverse proxy puede registrar un ticket ya gastado.

La versión corta: no escribas secretos en un bot al que no se los confiarías.

Conclusión

Bot Screen convierte «el bot se ha quedado atascado en una página de login» en un clic, un takeover y una devolución del control — con la pantalla permaneciendo en el servidor para que tu portátil pueda ir y venir. Desactivada por defecto, reclamada cuando está inactiva y condicionada por una comprobación explícita de memoria, no se comerá en silencio una instancia pequeña. Para profundizar, lee la guía de Bot Mode sobre cómo los profiles se convierten en bots con nombre, qué significa un contenedor Docker compartido para agentes en paralelo, y el resto de esta ventana en la página de la release v0.21.5.