Você vê que o Hermes Agent foi lançado de novo — a v0.21.6. Abre a página da release e o primeiro parágrafo já diz: é uma release de patch que reúne a janela em uma tag estável, e as notas curadas completas chegam com a v0.22.0. Você roda hermes update, o terminal diz que deu certo, e fica com uma pergunta que não consegue responder direito: o que eu realmente instalei, e devo me apressar? Desta vez aquela sensação incômoda é pior que o normal, porque não é só o conteúdo que é novo — a forma como a release foi produzida também mudou. Este post faz duas coisas: explica o que mudou no processo de release e te dá três comandos para confirmar a sua versão sozinho.

O que há de novo: a primeira tag do novo pipeline de releases estáveis

O texto oficial é direto: a v0.21.6 é a primeira release produzida pelo novo pipeline de releases estáveis, e o seu formato é “uma ref de tentativa, uma imagem Docker testada e uma tag de recibo na publicação”.

Isso soa abstrato, então aqui vai em palavras simples. Antes, a tag era o tiro de largada: a imagem, as implantações hospedadas e os pacotes Nix cada um se construía a partir dela depois. Agora a ordem se inverteu — existe uma tentativa de release primeiro, a própria tentativa carrega o build e os testes, a imagem Docker só é publicada depois de passar, e o recibo do que foi publicado fica registrado na tag. Para você, como usuário, a diferença prática é esta: a tag é respaldada por uma imagem que foi testada, em vez de uma tag que você constrói depois.

O texto também traça o limite: esta release entrega a tag, a GitHub release e a imagem Docker. O desktop app, os pacotes do Termux e a Microsoft Store ficam no build atual e se movem junto com a próxima release empacotada.

O quanto realmente entrou na janela

Primeiro o tamanho. Estes números são os oficiais, medidos no commit 818c13be1dc4fd28987e1e881a9408224afd4535:

Métrica	Valor
Commits não-merge	8.867
Arquivos alterados	8.342 (+772.490 / −225.600)
PRs mesclados	2.106
Issues fechadas	3.027

Se você quiser conferir a contagem de arquivos sozinho, um comando resolve (é preciso ter o histórico completo do git na sua máquina):

cd ~/.hermes/hermes-agent
git fetch origin main --tags
git diff --shortstat v2026.9.24 818c13be1dc4fd28987e1e881a9408224afd4535
# 8342 files changed, 772490 insertions(+), 225600 deletions(-)

v2026.9.24 é a tag anterior — ou seja, a versão semântica v0.21.5. “Uma release de patch sem notas” não quer dizer “nada dentro dela”; quer dizer que aqueles 2.106 PRs nunca foram nomeados e organizados individualmente. Eles serão documentados com a v0.22.0, e o texto promete que nada da janela é deixado de fora.

Três comandos para confirmar em qual versão você está

Não vá pela sensação, nem pela palavra “success” na saída do update. Vá pelo tipo de instalação:

# 1. número da versão (instalações via git também mostram a distância até a tag + commit curto)
hermes version

# 2. o que a sua última atualização realmente fez
hermes update

# 3. Docker / hospedado: olhe a própria tag da imagem
docker pull nousresearch/hermes-agent:stable

O terceiro caso merece um aviso. Usuários de Docker e Hermes Cloud não recebem uma árvore de trabalho do git, recebem uma imagem. A palavra-chave para consumidores downstream nesta release é nousresearch/hermes-agent:stable (ou :latest). Para quem usa imagem, existe exatamente uma resposta confiável para “eu atualizei?” — o digest da imagem, não o horário do pull que você lembra.

Há mais uma pista fácil de passar batido. Instalações via git registram como foram atualizadas num install stamp (install-stamp.json, lido por hermes version). Então, se duas máquinas relatam a mesma versão mas se comportam diferente, compare esse stamp antes de suspeitar do código — provavelmente você está vendo a diferença entre uma instalação “leve” e uma instalação completa via git.

As correções de segurança desta janela, em um só lugar

Esta release deliberadamente não documenta as suas funcionalidades, mas as correções de segurança são destacadas separadamente — três grupos, e vale a pena checar de que lado você está em cada um.

1. Endurecimento da autenticação do dashboard (PRs #133367, #133369, #133370, além do session takeover #130685). Um único relatório da Tenable Research (TRA-725 … TRA-728) cobre quatro problemas: um X-Forwarded-For forjado podia zerar o rate limit de login por senha e driblar o limite por IP; pedidos de login não autenticados podiam gravar valores ilimitados no log de auditoria; as rotas públicas /auth/ não tinham limite de tamanho do corpo da requisição; e o login nativo podia enviar códigos de login para um redirect que não fosse loopback, o que permitia session takeover. Já detalhamos os três primeiros em o post de endurecimento do login do dashboard — aquele texto traz a causa de cada um e se a sua implantação precisa de mudança de config. O quarto (o redirect) só é nomeado explicitamente no texto desta release, então leia os dois juntos para fechar o ciclo.

2. Endurecimento dos filtros git do repositório (#130661). Chamadas git automáticas — snapshots do workspace da sessão, worktrees de subagent, kanban, limpeza de worktree, hermes -w — podiam ser sequestradas por programas de filtro clean / smudge / process definidos no próprio config de um repositório não confiável, e isso acontecia antes de você digitar o primeiro prompt. Também cobrimos este em separado: quando o git config vira um ponto de entrada para RCE. Se você costuma clonar repositórios desconhecidos e abrir uma sessão dentro deles, este é o seu motivo para atualizar.

3. Endurecimento do remetente do gateway de e-mail (#125212, #124322). Um display name entre aspas no cabeçalho From podia ser forjado para parecer um remetente allowlisted, deixando a mensagem de um atacante passar pela allowlist de e-mail. Também analisamos este em o post de spoofing de identidade do remetente.

Em uma linha, os três grupos são a mesma classe de erro: entrada sem teto, confiada só porque chegou. Nenhum deles é uma funcionalidade.

Você deve atualizar agora?

Não é difícil decidir:

• Você expõe um dashboard, ou roda o gateway em várias máquinas ou profiles → atualize. Dois dos três grupos de segurança atingem diretamente a sua superfície de ataque.
• Você clona repositórios de outras pessoas e deixa o agent trabalhar dentro deles (especialmente os de times) → atualize. O problema do filtro git dispara antes de você dizer qualquer coisa.
• Você é uma única máquina local, sem portas expostas → nada quebra em nenhum dos casos, mas como o novo pipeline entrega uma imagem testada como artefato, se mover cedo sai mais barato do que se mover tarde.

A atualização continua sendo o mesmo one-liner: hermes update; usuários de Docker fazem pull da :stable; o desktop app não precisa de nada desta vez e segue a próxima release empacotada.

Para fechar

• A maior mudança na v0.21.6 não é uma funcionalidade — é como a release é produzida: ref de tentativa → imagem Docker testada → recibo registrado na publicação.
• Tamanho da janela: 8.342 arquivos alterados, 2.106 PRs mesclados. As notas curadas completas chegam com a v0.22.0.
• Não confie na palavra “success” do updater. Confirme com hermes version e o digest da imagem.
• Três grupos de segurança: autenticação do dashboard, filtros git, remetente de e-mail. Vale a pena agir sobre os dois primeiros hoje.

Para as mudanças da janela anterior que “já funcionam mas ninguém escreveu a respeito”, veja o nosso guia de autoverificação da janela de patch. E se você quiser saber exatamente o que sobrevive a um restart quando você liga o YOLO, leia em seguida /yolo persistence.