Você roda três perfis do mesmo bot numa única máquina: um vigia um canal de suporte, outro publica um resumo diário e um terceiro patrulha em segundo plano. Na segunda-feira você cria um quarto e ele simplesmente não aparece na lista de Bots do desktop — ao lado, o status do gateway diz “parado”, então você reinicia o gateway inteiro e, de quebra, interrompe as duas instâncias que estavam realmente trabalhando. Mas o que incomoda mais é a outra pergunta: esses perfis, na mesma máquina, enxergam em silêncio as credenciais, a memória e as sessões uns dos outros?

O v0.21.2 responde às duas coisas. Não há nenhum recurso de destaque nesta versão: os dois objetivos são bem simples — que cada perfil da máquina guarde o que é seu, e que o desktop pare de abrir um backend para cada perfil.

Um processo de gateway, três conjuntos de bots

Antes de tudo: um perfil é, na prática, uma instalação independente do Hermes, com configuração própria, credenciais próprias, memória própria e histórico de sessões próprio. Para que vários perfis numa mesma máquina não precisem de um gateway cada um, o Hermes traz um multiplexador — um único processo de gateway que hospeda ao mesmo tempo os bots de vários perfis. Compartilhar esse processo é exatamente a vantagem e exatamente o risco: tudo o que é resolvido “globalmente” dentro dele pode vazar de um perfil para outro.

A forma típica dessas instalações é um perfil principal mais alguns perfis secundários, compartilhando o processo e parte do estado em tempo de execução. Se você quer organizar sua máquina assim, o guia de perfis em várias instâncias mostra o que pode ser compartilhado e o que precisa ficar separado.

O v0.21.2 (tag v2026.9.11, lançado em 11 de setembro de 2026, apelidado oficialmente de “The state.db Patch Release”) é a versão de correções que vem logo depois do v0.21.1, e não é pequena: desde o v0.21.1 são 947 commits que não são de merge, 1.869 arquivos alterados (+182.504 / -15.564) e 312 pull requests mescladas, vindas de 140 contribuidores. A lista completa por blocos está na página de lançamento do v0.21.2; abaixo estão as partes que não têm nada a ver com state.db, mas que mudam o seu dia a dia.

Sete vazamentos fechados de uma vez

O que dá medo numa instalação com vários perfis não é uma falha, e sim um vazamento silencioso: um perfil usando permissões, segredos ou arquivos de outro, com todas as telas parecendo normais. Sete pull requests desta versão miram exatamente isso:

PR	O que cruzava a linha	Comportamento agora
#107616	Os bots de um perfil secundário herdavam a allow-list do perfil padrão; a lista de permissões era resolvida entre perfis	cada perfil resolve a própria allow-list
#107617	Adaptadores podiam enviar credenciais para o host do perfil padrão	as credenciais viajam com o perfil a que pertencem
#107630	Servidores MCP via stdio recebiam os segredos do vault do perfil padrão	recebem apenas os segredos do perfil atual
#107609	A entrega de MEDIA: podia carregar o .env, o auth.json ou o state.db de outro perfil	a entrega fica restrita ao perfil que a iniciou
#107620 / #107626	Callbacks do Feishu drive, e respostas de webhook num caminho próprio de um perfil, podiam cair em outro perfil	callbacks e respostas ficam no perfil roteado
#107611	Um perfil secundário podia pegar o token bearer da Nous de um perfil irmão na memória do processo	tokens não são mais reutilizados entre perfis

O #107616 merece uma frase só para ele. A allow-list define a fronteira de permissões de um bot, e antes ela era resolvida contra o perfil padrão: tudo o que você tinha aberto no perfil principal era herdado por um perfil secundário. Para dois bots com trabalhos sem relação, isso significava entregar as permissões do principal ao outro. O contexto desse caso está em o artigo sobre a allow-list por perfil.

Lendo a tabela inteira, sai um teste útil: tudo o que é compartilhado “no nível do processo” — memória interna, o vault, hosts de adaptadores, canais de entrega — sempre foi o ponto fraco do modo multi-perfil. Esta leva não corrige caso a caso: ela amarra cada ponto de resolução de volta à fronteira do perfil.

O desktop para de abrir um backend por perfil

O segundo bloco é o comportamento de inicialização do Bot Mode no desktop, e o sintoma era bem visível. Antes, na inicialização e a cada tick do roster, o desktop gerava ou discava um backend para cada perfil; passar o mouse pela lista de Bots gerava um backend para cada linha; trocar de perfil podia gerar backends primários duplicados. Quantos perfis você tivesse, tantos múltiplos de processos de backend se acumulavam, e os extras disputavam o mesmo gateway.

Esta versão mexe tanto no caminho de inicialização quanto na renderização da lista: #108069, #108107, #108118, #108134, #107969, #108112. Na prática, a cena do começo do texto deixa de acontecer: adicionar um perfil não obriga mais a reiniciar o gateway de madrugada, e a lista de Bots não ganha mais entradas fantasma com status duvidoso.

As correções do “isso não faz sentido”

Além desses dois blocos, a versão limpa uma série de comportamentos pequenos que incomodavam em silêncio há muito tempo. Nenhum é dramático sozinho; juntos, formam uma parede em que você bate todo dia.

Cron. Um “executar agora” fora da hora cheia não cancela mais a próxima execução agendada (#106306); uma execução manual que você matou não bloqueia mais a janela seguinte de cinco minutos (#106733); uma tarefa alterada de pontual para recorrente continua disparando (#106532); uma tarefa sem modelo fixado roda com o modelo capturado no momento da criação (#106499); e hermes profile create --clone-all não copia mais as tarefas de cron junto (#106478). Esse último ponto é o que mais importa para quem usa vários perfis, porque clonar um perfil costuma ser sobre reaproveitar configuração, e não sobre rodar a mesma tarefa agendada uma segunda vez no segundo perfil.

Kanban. O kanban promote agora recusa uma tarefa pai não concluída (#106550), e o kanban_request_review recusa um perfil revisor desconhecido (#106547). Os dois transformam “aceitar em silêncio uma entrada ruim” em “recusar com clareza”.

Ferramentas e memória. Quando um servidor MCP via stdio morre no meio de uma chamada, a chamada de ferramenta não é mais repetida (#106546) — repetir significa que uma escrita que talvez já tenha sido executada acontece uma segunda vez, o que torna essa correção especialmente valiosa. Uma revisão em segundo plano feita só de skills não pode mais apagar entradas de memória (#106310); a memória mem0 não perde mais turnos longos (#106542); o tool_search prefere não devolver nada a devolver cinco ferramentas sem relação que só compartilham uma palavra (#106676); o sudo NOPASSWD remoto não dispara mais um pedido de aprovação (#107939); e a leitura de RSS e Reddit não vem mais ligada por padrão (#105873).

Atualizações e cota. A checagem de atualização agora consulta a API do GitHub uma vez por dia, em vez de fazer um git fetch a cada 30 minutos (#107648); o hermes update informa o motivo real de uma falha e não trava mais num fetch parado (#108053).

Provedores e roteamento. O /model e o roteamento automático auxiliar não cobram de um provedor que você não escolheu (#107366); o Hermes nunca troca sozinho para um provedor para o qual você não tem credenciais (#107281); as Bedrock Guardrails passam a valer (#107815).

Cache. Alternar entre o desktop e a TUI não reconstrói mais o system prompt e, portanto, não quebra mais o cache de prompt (#105844) — uma economia real para quem fica pulando entre as duas interfaces o dia inteiro.

O que você deve fazer

Atualizar é um único comando:

hermes update

Depois, vale confirmar algumas coisas:

• Se você configurou uma allow-list de permissões numa máquina com vários perfis, agora cada perfil resolve a sua (#107616): verifique se as listas dos perfis secundários são mesmo o que você quer.
• Se você contava com o hermes profile create --clone-all para levar as tarefas de cron junto, agora precisa recriá-las na mão (#106478).
• Se quiser continuar usando RSS ou Reddit como fontes de conteúdo, ative-os explicitamente: por padrão ficam desligados (#105873).
• Se uma tarefa agendada não tem modelo fixado, ela agora roda com o modelo capturado no momento da criação (#106499).
• A checagem de atualização passou a rodar uma vez por dia (#107648): não entenda isso como lentidão, ela só parou de buscar dados a cada meia hora.

Uma última linha sobre o trabalho no state.db, que não é o tema aqui: o v0.21.0 reescreveu o tratamento de conexões do armazenamento de sessões, o que deixou o state.db frágil em algumas instalações, e o v0.21.2 fecha essa classe de problemas. Tratamos disso em separado — os detalhes estão em travamentos e conflitos de escrita do state.db.

Conclusão

O v0.21.2 é um patch de reforço clássico: nenhum recurso para exibir, e 947 commits que não são de merge e 312 pull requests mescladas gastos em grande parte em trazer as fronteiras de volta. Para quem roda um único perfil, a mudança mais visível é provavelmente que o desktop deixa de carregar uma pilha de backends fantasma. Para quem roda vários perfis numa máquina, a versão importa muito mais: da allow-list de permissões aos segredos do vault e aos hosts de credenciais, até os tokens na memória do processo, sete vazamentos entre perfis se fecham de uma vez.

Os vários perfis deixam de ser uma configuração que “funciona, mas você nunca fica tranquilo”: cada perfil guarda o que é seu e o desktop abre somente os backends de que precisa. É exatamente isso que esta versão conserta.