Você fecha o laptop para entrar numa call, volta depois e o desktop do Hermes carrega normalmente — e então pede para você fazer login de novo. Ninguém derrubou a sua conta: foi o seu próprio cliente que invalidou a sessão. Isso acontece com mais frequência quando você usa um gateway remoto junto com o desktop, e sempre escolhe o momento em que você menos quer lidar com isso.

A v0.21.3 (tag v2026.9.14, lançada em 14 de setembro de 2026, apelidada de “The Sign-In Patch”) existe para essa falha. Ela também é um canal de atualização para usuários de nuvem: as imagens Docker e o Hermes Cloud são construídos a partir da tag de release mais recente, então uma correção precisa ser consolidada numa tag estável antes de alcançar instalações que nunca rodam hermes update na mão.

Por que um burst de despertar pode invalidar uma sessão inteira

Comece pelas peças. Para acesso remoto, um cliente carrega um par de tokens: um access token (de vida curta, usado nas requisições) e um refresh token (de vida longa, usado para obter novos access tokens). Para limitar o estrago de um vazamento, o authorization server rotaciona o refresh token a cada uso — o valor antigo morre na hora e só o novo vale. Se o valor antigo for apresentado uma segunda vez, o servidor entende que é um token roubado, e a resposta protetiva é revogar a sessão inteira.

O problema é que existem dois caminhos de refresh: o cookie gate do gateway e a rota bearer nativa do próprio desktop. Os dois seguram o mesmo refresh token rotativo. Quando o desktop desperta da suspensão, ele dispara várias requisições de uma vez — um burst natural — e os dois caminhos fazem refresh quase simultaneamente, então o mesmo valor antigo é apresentado duas vezes e a sessão é deslogada pelo próprio cliente (#110061, corrige a #55712).

A correção coalesce esses refreshes: quando requisições concorrentes carregam o mesmo token rotativo, uma faz a rotação e as demais adotam o resultado em vez de apresentar o token de novo. O refresh também saiu do event loop, então um identity provider lento não congela mais o /api/status enquanto espera.

Do lado do Portal a mudança vem acompanhada (hermes-portal#1209): um horizonte ocioso deslizante de 30 dias mais uma janela de tolerância de 5 minutos para um token rotacionado, de modo que uma requisição genuinamente em andamento com o valor recém-rotacionado não seja lida como reúso.

A correção mais silenciosa: handles de escrita duplicados no state.db

A mesma janela traz outra correção de armazenamento de sessões, essa escondida nos logs. Se você já viu um aviso N live SessionDB handles durante diagnósticos, ele deveria significar “mais de um processo escreve neste banco” — mas também disparava em topologias saudáveis (#110934, corrige as #100896 e #103339).

O gateway, o backend do dashboard/Desktop, a superfície ACP e os leitores de CLI anexavam cada um o seu próprio handle de escrita. A regra agora é explícita: os leitores se anexam em modo somente leitura, e os writers no mesmo processo compartilham o único handle do registro. Menos handles significa menos chances de um componente cancelar os locks de outro — exatamente a classe de falha que o patch da v0.21.2 fechou com seis PRs, e a mesma descrita no nosso post de troubleshooting do state.db.

O que mais tem na v0.21.3 (documentado como deve na v0.22.0)

A v0.21.3 é uma tag ambulante: os ~338 PRs mesclados, os 1.036 commits não-merge e os 2.642 arquivos alterados desde a v0.21.2 ficam todos nessa janela. A maior parte foi deixada de propósito para as notas da v0.22.0, então aqui está o formato do que vem por aí, por área:

Área	O que foi lançado
Contrato do gateway	Requisições JSON-RPC de servidor→cliente substituem os pares de eventos *.request / *.respond (#110521); um registro de wire contract em Pydantic gera os tipos TypeScript e OpenRPC (#110522, #110523)
Modelos e reasoning	Reasoning effort em todo seletor de modelo; um pill no composer e controle de effort por auxiliary no Desktop; login OpenRouter OAuth PKCE
MCP	Refresh tokens de OAuth vinculados ao issuer que os concedeu; um lembrete diário de re-autenticação no Desktop
Mídia	Decodificação de imagens HEIF / HEIC / AVIF
Providers	Wan 3.0, Kling 3.0 / Kling Image v3, MiniMax H3 Max Turbo, Gemini Omni Flash 1.1 e Meta Muse nos catálogos FAL; a configuração de peer-model do Honcho refeita
Plataformas	Tabelas coladas no Slack e a Agent Sessions API
Armazenamento e profiles	Isolamento de profile multiplexado e correções de liveness do gateway; uma recusa a rodar o modo de journal WAL em filesystems entre VMs

A lista bloco a bloco fica na página de release da v0.21.3, e o diff da janela está em v2026.9.11…v2026.9.14.

O que você deve fazer

Instalações manuais se atualizam com um comando:

hermes update

Docker e ambientes hospedados são reconstruídos a partir da nova tag:

docker pull nousresearch/hermes-agent:v2026.9.14

Se as suas sessões costumavam morrer depois que o desktop despertava, vale pegar esta atualização primeiro. Se nunca morreram, o seu padrão de uso simplesmente não caiu na janela de concorrência — a atualização é igualmente segura.