Seu bot trava às 3 da manhã num portal de fornecedor que pede login. Ele avisa isso no chat e encerra o turno, e tudo depois disso é chute: em que página ele parou, se bagunçou o formulário que enviou um minuto antes. Quando você chega, a sessão já esfriou, e ele pode ter clicado em outra coisa enquanto isso. O Bot Screen existe para eliminar esse chute. Num host Linux headless, cada perfil agora tem seu próprio desktop, transmitido ao vivo no Hermes Desktop. Você pode ver o bot trabalhar, assumir o teclado e o mouse quando ele precisar de você, e depois devolver o controle e deixar ele seguir.

O que isso é, na prática

Em uma frase: cada bot ganha seu próprio desktop Xfce, rodando no host do gateway.

• O computer_use do bot (automação de desktop) e seu navegador com interface (browser.headed: true) agem nessa tela.
• A tela é transmitida para um painel no Hermes Desktop via noVNC.
• Cada perfil tem sua própria tela, seu próprio perfil de navegador e seus próprios cookies.
• A parte importante: a tela mora no host do gateway, não no seu laptop. Feche o app, baixe a tampa — o bot continua trabalhando no servidor.

Essa é a diferença em relação a “área de trabalho remota de volta para a minha máquina”: o agente roda no servidor, o desktop roda no servidor, e seu cliente é só uma janela para ele.

Para que você usa: logins, 2FA, CAPTCHAs, pagamentos

O bot não deveria fazer essas etapas sozinho, e não deveria bloquear esperando por você:

1. Ele bate num passo de login, 2FA, CAPTCHA ou pagamento, avisa isso na resposta e encerra o turno.
2. O pedido chega até você no chat em que estiver — Telegram, Slack, Desktop.
3. Quando você tiver tempo, abra o painel e clique em Take over. A borda fica vermelha; seu teclado e seu mouse passam a comandá-lo.
4. Faça login, resolva o CAPTCHA, aprove o pagamento.
5. Clique em Hand back. O bot recupera o controle e captura a tela de novo antes de continuar.

Dois detalhes merecem atenção. Um bot nunca mantém um tool call aberto esperando por você — assumir o controle é sempre uma iniciativa sua. E quando dois visualizadores disputam uma mesma tela, o Take over mais recente vence; o controlador anterior volta para o modo de observação. “Hand back” e “conexão caiu” também são coisas diferentes: se sua tampa fecha ou o Wi-Fi cai enquanto você detém o controle, ele continua com você — o bot fica fora de uma tela em que você pode estar no meio de um login — até você reconectar e devolver o controle. Se um recarregamento deixar o painel afirmando que um humano ainda detém o controle, aparece um botão Hand back (force).

Como começar

Requisito: o host do gateway roda Linux. Hosts macOS e Windows já têm um display real, e o painel não é oferecido neles.

Os pacotes de desktop (o Xvnc do TigerVNC mais o núcleo do Xfce) nunca são instalados em silêncio — o hermes update e as instalações do zero deixam a máquina como está. Quando eles faltam, o painel do Desktop mostra Install on host: um clique roda o gerenciador de pacotes naquele host, pedindo a senha de sudo daquele host num card mascarado (a senha vai só para aquele host e nunca é armazenada).

A imagem Docker oficial — que também move o Hermes Cloud — é o outro caso: o gateway roda como usuário sem privilégios e a imagem não tem sudo, então o painel imprime a linha exata e um operador a roda uma vez como root dentro do container:

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

As mesmas operações a partir de um shell:

hermes computer-use screen status     # instalada? rodando? quem detém o controle?
hermes computer-use screen start      # inicia a tela deste perfil
hermes computer-use screen stop       # recusa enquanto um humano detém o controle
hermes computer-use screen stop --force   # força, e limpa um lease travado
hermes computer-use screen install [-y]   # roda apt/dnf/pacman
hermes -p research computer-use screen start   # a tela de outro perfil

A tela vem desligada por padrão e nada a inicia para você. bot_desktop.auto_start é false; ligue e um host headless sobe sua tela na primeira chamada de computer_use do bot ou no primeiro uso de navegador com interface. O padrão é proposital — instalar o TigerVNC por motivos alheios não deveria conjurar uma tela que ninguém pediu.

bot_desktop:
  geometry: "1440x900"      # tamanho da tela; o visualizador escala para caber no painel
  auto_start: false         # true = inicia no primeiro computer_use / uso de navegador com interface
  min_free_memory_mb: 1536  # recusa iniciar abaixo dessa memória livre (0 = nunca verificar)
  idle_stop_minutes: 30     # para uma tela sem uso por esse tempo (0 = mantê-la de pé)

Faça as contas de memória primeiro

O desktop é barato; o navegador é o custo. Medido na imagem oficial:

Item	Consumo
Gateway ocioso	~300 MB
Xvnc + Xfce	~220 MB
Chromium com interface aberto durante um takeover	0,5–1 GB (~550 MB para uma página)
CPU	praticamente nada (desktop ocioso ≈ 0,01 core)
Disco, pacotes no Debian 13	~930 MB

Reserve 1,1–1,5 GB por tela aberta com um navegador. A orientação oficial: 4 GB roda o desktop, 8 GB é onde um takeover com navegador fica confortável. Antes de iniciar, o Hermes verifica se o host — ou o cgroup de seu container, o que for mais apertado — tem min_free_memory_mb livres; abaixo disso ele recusa e diz isso no painel, e uma tela já em execução nunca é derrubada por essa verificação. Telas ociosas param depois de idle_stop_minutes (30 por padrão) e voltam no uso seguinte.

Novidade desde 2026-09-23: duas variantes de imagem

Um deployment hospedado (Fly Machines, Azure container instances) não pode instalar nada em tempo de execução, então os pacotes precisam vir na build. O CI agora publica duas variantes de cada versão:

• as tags sem sufixo (:latest, :v*) — sem os pacotes;
• as tags -desktop (:latest-desktop, :v*-desktop) — com TigerVNC, os componentes do Xfce e o Chromium da distro.

Puxe a tag com sufixo numa instância hospedada e o Bot Screen está lá. A ressalva de hoje, dita sem rodeios na documentação: nada no provisioner seleciona -desktop ainda, então uma instância hospedada continua subindo enxuta — puxar a tag com sufixo por conta própria funciona. Montar sua própria imagem também é opcional; o argumento de build oficial vem desligado por padrão, para que um simples docker build . continue enxuto:

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

Um dia depois (2026-09-24) chegou uma mudança companheira: toda imagem, incluindo as tags enxutas sem desktop, agora carrega a build completa do Chromium em vez do shell headless mais leve do Playwright — um único navegador fixado e com checksum atende tanto a navegação headless quanto as sessões do Bot Screen com interface, ao custo de uma imagem maior.

As sessões de navegador sobrevivem à passagem do controle

Esta é a parte mais prática do Bot Screen: a tool de navegador do bot e o ícone Browser do painel são o mesmo navegador. Cada bot carrega um diretório de dados de usuário persistente (<HERMES_HOME>/bot-desktop/browser-profile), então durante um takeover você está nas próprias janelas e no próprio pote de cookies do bot — e aquilo em que você faz login é o que o bot usa depois, nesta execução e em toda sessão seguinte, até o site expirar o login.

Defina browser.headed: true se quiser que a navegação do próprio bot também apareça na tela. Note que o dock é semeado uma vez, na primeira inicialização da tela de um perfil: a guarda é o arquivo de layout do painel <HERMES_HOME>/bot-desktop/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml. Enquanto ele existir, mudar AGENT_BROWSER_EXECUTABLE_PATH ou AGENT_BROWSER_PROFILE e reiniciar não fixa o ícone Browser de novo — apague esse arquivo e o dock se reconstrói no próximo screen start.

A fronteira de segurança: uma superfície de trabalho, não um sandbox

A documentação diz isso sem meias palavras, e vale repetir o espírito literalmente: o socket RFB da tela, o display X, o perfil de navegador e o arquivo de lease de controle pertencem todos ao usuário de OS do gateway. Qualquer processo rodando como esse usuário — outro bot no mesmo host, e a própria tool terminal do bot — pode alcançá-los diretamente, contornando o painel e o lease. O lease é uma cerca no nível das tools, sobre o computer_use e as tools de navegador, não no nível do OS.

Uma fronteira é mais larga que o usuário de OS: a porta DevTools do Chromium (o Browser do dock e todo lançamento do agent-browser anunciam uma no loopback) é alcançável por qualquer usuário local do host, e o Chromium não oferece restrição por usuário para isso. Rodar cada bot como seu próprio usuário de OS está fora de escopo; se esse isolamento importa, ou o host tem usuários locais não confiáveis, coloque os bots em hosts separados.

Dois detalhes de tempo: a ponte WebSocket faz cache da sua decisão de lease por até 250 ms, então um takeover feito por outro processo é aplicado dentro dessa janela. E o display_ticket de uso único e 30 segundos do visualizador viaja como parâmetro de query na URL de propósito (o noVNC não consegue negociar subprotocolos de WebSocket), o que significa que o log de acesso de um proxy reverso pode registrar um ticket já gasto.

A versão curta: não digite segredos num bot em quem você não confiaria esses segredos.

A conclusão

O Bot Screen transforma “o bot travou numa página de login” de um chute às cegas em um clique, um takeover e uma devolução — com a tela permanecendo no servidor, para que seu laptop vá e volte à vontade. Desligado por padrão, recuperado quando ocioso e condicionado a uma verificação explícita de memória, ele não vai consumir silenciosamente uma instância pequena. Para ir mais fundo, leia o guia do Bot Mode para entender como perfis viram bots nomeados, o que um container Docker compartilhado significa para agentes em paralelo e o resto desta janela na página da release v0.21.5.