Se o seu Hermes roda dois profiles ao mesmo tempo — um conectado ao servidor da empresa, outro ao NAS de casa — leia isto antes de qualquer coisa: o #92156, mesclado na main em 22 de agosto, corrige um vazamento que pode fazer você rodar comandos no host errado. Parece algo profundamente técnico, mas a consequência é direta: depois de alternar entre profiles, os comandos do seu terminal podem continuar usando silenciosamente o ambiente SSH em cache do profile anterior — ou seja, um comando que você achava que tinha rodado no servidor A na verdade executou no servidor B.

Como o Vazamento Acontecia

A ferramenta de terminal do Hermes mantém em cache o ambiente remoto de cada sessão (como o SSHEnvironment) para não precisar restabelecer conexões a cada comando. Esse cache fica em um dict chamado _active_environments, indexado por uma chave gerada por _resolve_container_task_id().

O problema era justamente essa chave: todas as sessões do WebUI / gateway caíam na mesma chave compartilhada "default". Assim, no mesmo processo, o Profile A (ssh_host=10.0.0.1) e o Profile B (ssh_host=10.0.0.2) dividiam um único slot de cache — depois de alternar entre profiles, o terminal do B podia pegar o ambiente SSH em cache do A, e os comandos rodavam silenciosamente em 10.0.0.1 em vez do 10.0.0.2 que você pretendia.

Via SSH isso é especialmente perigoso: rm, git push, edições de configuração — rodar no host errado significa ações destrutivas no alvo errado, sem nenhum aviso, porque a saída parece completamente normal.

A Correção: Cache com Escopo por Sessão

A correção do #92156 é simples: a chave do cache mudou de "default" para session:<key>.

• A camada de streaming do WebUI define uma chave de sessão dedicada para cada sessão;
• o gateway injeta uma chave de sessão por mensagem via contextvars;
• após uma troca de profile (sessão), a nova sessão recebe uma chave de cache diferente e não consegue mais reutilizar o SSHEnvironment do profile anterior — então os comandos não podem mais ser enviados ao host errado.

Vale notar o que a correção não quebra: os subagentes continuam compartilhando o container de longa duração do agente pai, e os ambientes de RL / benchmark (TerminalBench2, etc.) mantêm o isolamento por tarefa — esses caminhos têm regras próprias de chave, e os filhos de delegate_task seguem compartilhando a conexão da sessão do agente pai.

O Que Você Deve Fazer

1. Usuários de multi-profile + SSH: atualizem para um build que contenha a correção (hermes update --branch main, ou esperem o próximo release — a versão estável mais recente ainda é a v0.20.5);
2. Verifiquem: configure dois profiles com hosts remotos diferentes, rode hostname ou echo $SSH_CONNECTION em cada um e confirme se a saída corresponde à configuração de cada profile;
3. Dica geral: configurações com vários profiles são abordadas em Hermes Profiles: Múltiplas Instâncias Independentes; as chaves de configuração de terminal/env também aparecem em 4 Truques Escondidos do Hermes.

Status do Release

A correção (#92156) foi mesclada na main (22 de agosto) e ainda não está em nenhum release. Para testar antes: hermes update --branch main. Ela faz parte do mesmo lote de endurecimento do gateway/terminal do fim de agosto, junto com o guia de ajuste do loop-watchdog.

Conclusão

O vazamento de ambiente SSH entre profiles é uma armadilha invisível: não é um erro, mas rodar silenciosamente no host errado. A boa notícia é que a correção já está na main — com o cache com escopo por sessão, alternar entre profiles não consegue mais carregar o ambiente remoto do profile anterior. Se você usa muitos profiles, vale a pena atualizar e verificar imediatamente.