Bot Screen: um desktop por bot, com o humano a poder assumir

Num servidor sem ecrã — uma VM, um container, o gateway na nuvem — o computer_use de um bot trabalha às cegas: clica, escreve e autentica num monitor que ninguém vê. Enquanto tudo corre por APIs, sem problema. O problema aparece quando, a meio de uma tarefa, o bot dá de caras com um login, um código 2FA, um CAPTCHA ou um pagamento — e tem de parar: não pode, nem deve, resolver isso sozinho.

O Bot Screen resolve exatamente esse vão. Cada perfil — cada “bot” — ganha o seu desktop Xfce num host Linux headless, servido por um Xvnc do TigerVNC e transmitido em direto para o Hermes Desktop. Vês o que o bot faz, clicas Take over, a borda fica vermelha e o teclado e o rato passam a ser teus; resolves o que só um humano resolve, clicas Hand back, e o bot retoma a sessão — já autenticada. O ecrã vive no host do gateway, não na tua máquina: o bot continua a trabalhar depois de fechares a app ou desligares o portátil.

Chega com a v0.21.5 (tag v2026.9.24, 24 de setembro), que trouxe o Bot Screen também para as imagens alojadas -desktop. É daquelas funcionalidades que mudam o que se pode pedir a um bot: sem ela, tudo o que passe por um login fica fora do alcance de um agente headless.

Como se usa

Tudo o que a app faz tem equivalente na shell, e os comandos são diretos:

hermes computer-use screen status          # instalado? a correr? quem tem o controlo?
hermes computer-use screen start           # arranca o ecrã deste perfil
hermes computer-use screen stop            # para-o (recusa enquanto um humano tem o controlo)
hermes computer-use screen stop --force    # ...a não ser que forces (também liberta uma lease presa)
hermes computer-use screen install [-y]    # instala os pacotes via apt/dnf/pacman do host
hermes -p research computer-use screen start   # o ecrã de outro perfil

No Hermes Desktop, o ecrã aparece em três sítios: em Bots → bot → Scheduled Jobs há uma pré-visualização ao vivo no topo do painel; com o clique-direito num bot tens Open Screen (e Open Screen when the bot uses it, que traz o separador à frente no primeiro computer_use); e o mesmo bloco Screen surge no sidebar de Sessões, sob o cabeçalho de cada perfil. O ecrã está desligado por omissão — nada o arranca por ti.

Configuração

As chaves de bot_desktop:

bot_desktop:
  geometry: "1440x900"      # tamanho do ecrã
  auto_start: false         # true → arranca no primeiro computer_use ou browser headed
  min_free_memory_mb: 1536  # recusa arrancar abaixo disto (0 = nunca verifica)
  idle_stop_minutes: 30     # para um ecrã sem uso durante tanto tempo (0 = manter)
  placement: auto           # auto | terminal | gateway

O auto_start é a peça que interessa num host verdadeiramente headless: a true, o ecrã arranca sozinho na primeira vez que o bot precisa de um display, sem esperares por um clique em Start screen. E só se paga o desktop enquanto algo está em cima dele.

O ecrã vive onde o terminal vive

placement decide onde corre. Com auto, segue o backend do terminal: no host quando terminal.backend: local; dentro do sandbox quando é docker, ssh ou singularity, para o computer_use e o browser nunca agirem fora dessa fronteira. gateway força o host, terminal força o sandbox.

Não é um instantâneo do que está a correr: com o ecrã no sandbox, a primeira chamada ao browser ou ao computer_use fá-lo subir ali a pedido — sem auto_start — e, quando não consegue, a chamada falha com a razão. O host nunca é o fallback de um sandbox cujo ecrã está em baixo. Os backends modal, daytona e vercel_sandbox ainda recusam alojar um ecrã; nesses casos, a resposta é placement: gateway.

Sessões de browser que sobrevivem ao handoff

Este é o pormenor que faz a diferença. Enquanto o ecrã corre, o browser do bot e o ícone Browser da dock são o mesmo Chromium, com um perfil persistente por bot. Se, durante o takeover, abrires o browser, estás nas janelas e nos cookies do bot: o que autenticas passa a ser o que ele usa depois, nas sessões seguintes, até o site expirar o login. Com browser.headed: true, o browsing do bot também é visível no ecrã.

O que costuma correr mal

• A lease é uma vedação de ferramentas, não do sistema operativo. Enquanto tens o controlo, as ferramentas computer_use e browser do bot são recusadas com human_has_control, capturas incluídas. Mas o bot corre como o mesmo utilizador que o ecrã: não é uma fronteira de segurança. Não escrevas segredos num bot em quem não confiarias.
• O bot diz human_has_control depois de saíres. Acontece quando uma ligação cai a meio de um takeover. Clica Hand back (ou Hand back (force), após recarregar); do shell, hermes computer-use screen stop --force liberta a lease e para o ecrã.
• Teclas erradas durante um takeover. O ecrã corre um keymap US, por isso, num teclado físico não-US, as teclas dependentes do layout (Y/Z, símbolos) saem como as homólogas US. Tem isso em conta ao digitar passwords.
• “Screen packages missing”. Instala no host do gateway, não na máquina que corre o Hermes Desktop — pelo botão Install on host ou por hermes computer-use screen install. O hermes update não toca na máquina.
• WSL2. O WSLg monta /tmp/.X11-unix em só-leitura e o Xvnc morre com Cannot establish any listening sockets no launcher.log. Substitui a montagem por um diretório gravável antes de arrancar o ecrã.
• Custo. Os pacotes ocupam ~930 MB em Debian 13. Em memória, o desktop Xfce+Xvnc anda pelos ~220 MB; um browser num takeover acrescenta 0,5–1 GB — planeia ~1,1–1,5 GB por ecrã com browser.

Fecho

Gosto desta funcionalidade por uma razão pouco vistosa: assume que há passos que um bot não deve dar sozinho, e desenha tudo à volta disso — o bot para e pede, tu assumes, resolves, devolves. Para quem corre agentes num servidor sem ecrã, é a diferença entre “não dá por causa do login” e “trata disso por mim”.

Docs: Bot Screen · Release v2026.9.24