Hermes v0.21.3: tu sesión de escritorio deja de cerrarse sola tras dormir


Cierras el portátil para entrar en una llamada, vuelves y el escritorio de Hermes carga con normalidad — y acto seguido te pide iniciar sesión otra vez. Nadie echó a tu cuenta: fue tu propio cliente el que invalidó la sesión. Ocurre sobre todo cuando usas un gateway remoto y el escritorio a la vez, y siempre elige el momento en que menos ganas tienes de lidiar con ello.

v0.21.3 (tag v2026.9.14, publicada el 14 de septiembre de 2026, con el apodo «The Sign-In Patch») existe por ese fallo. También es un canal de actualización para los usuarios de la nube: las imágenes Docker y Hermes Cloud se construyen a partir del tag de release más reciente, así que un arreglo tiene que entrar en un tag estable antes de llegar a las instalaciones que nunca ejecutan hermes update a mano.

Por qué una ráfaga al despertar puede invalidar toda una sesión

Empecemos por las piezas. Para el acceso remoto, un cliente guarda un par de tokens: un access token (de vida corta, se usa en las peticiones) y un refresh token (de vida larga, sirve para obtener access tokens nuevos). Para limitar el daño de una filtración, el servidor de autorización rota el refresh token en cada uso — el valor antiguo muere al instante y solo cuenta el nuevo. Si el valor antiguo se presenta una segunda vez, el servidor lo interpreta como un token robado, y la respuesta protectora es revocar la sesión entera.

El problema es que existen dos rutas de refresh: la puerta de cookie del gateway y la ruta bearer nativa del propio escritorio. Ambas sostienen el mismo refresh token rotatorio. Cuando el escritorio despierta tras dormir, dispara varias peticiones a la vez —una ráfaga natural— y las dos rutas refrescan casi al mismo tiempo, de modo que el mismo valor antiguo se presenta dos veces y el cliente acaba cerrando su propia sesión (#110061, corrige #55712).

El arreglo fusiona esos refresh: cuando varias peticiones concurrentes llevan el mismo token rotatorio, una hace la rotación y las demás adoptan su resultado en lugar de presentar el token otra vez. El refresh también se movió fuera del event loop, así que un proveedor de identidad lento ya no congela /api/status mientras espera.

El lado de Portal acompaña este cambio (hermes-portal#1209): un horizonte de inactividad deslizante de 30 días más una ventana de gracia de 5 minutos sobre un token rotado, para que una petición genuinamente en vuelo con el valor recién rotado no se lea como reutilización.

El arreglo más silencioso: handles de escritura duplicados sobre state.db

La misma ventana trae otro arreglo de almacenamiento de sesiones, este escondido en los logs. Si alguna vez has visto un aviso N live SessionDB handles durante los diagnósticos, debía significar «más de un proceso escribe esta base de datos», pero también saltaba en topologías sanas (#110934, corrige #100896 y #103339).

El gateway, el backend del dashboard/escritorio, la superficie ACP y los lectores de la CLI adjuntaban cada uno su propio handle de escritura. La regla ahora es explícita: los lectores se adjuntan en solo lectura, y los escritores dentro del proceso comparten el único handle del registro. Menos handles significa menos ocasiones de que un componente cancele los bloqueos de otro — exactamente la clase de fallo que el parche v0.21.2 cerró con seis PRs, y la que describe nuestro artículo de diagnóstico de state.db.

Qué más trae v0.21.3 (documentado como es debido en v0.22.0)

v0.21.3 es un tag acumulativo: los ~338 PRs fusionados, los 1,036 commits no de merge y los 2,642 archivos modificados desde v0.21.2 están todos en esta ventana. La mayor parte se deja a propósito para las notas de v0.22.0, así que aquí va la forma de lo que viene, por área:

Área Qué se publicó
Contrato del gateway Las peticiones JSON-RPC de servidor→cliente sustituyen a los pares de eventos *.request / *.respond (#110521); un registro de contratos de cable en Pydantic genera los tipos de TypeScript y OpenRPC (#110522, #110523)
Modelos y razonamiento Esfuerzo de razonamiento en cada selector de modelo; una píldora en el composer y control de esfuerzo por auxiliar en el escritorio; login OpenRouter OAuth PKCE
MCP Los refresh tokens de OAuth quedan vinculados al emisor que los concedió; un recordatorio diario de re-autenticación en el escritorio
Media Decodificación de imágenes HEIF / HEIC / AVIF
Providers Wan 3.0, Kling 3.0 / Kling Image v3, MiniMax H3 Max Turbo, Gemini Omni Flash 1.1 y Meta Muse en los catálogos de FAL; la configuración de peer-model de Honcho rehecha
Plataformas Tablas pegadas en Slack y la Agent Sessions API
Almacenamiento y profiles Aislamiento de profiles multiplexados y correcciones de vivacidad del gateway; la negativa a ejecutar el modo journal WAL en sistemas de archivos entre VMs

La lista bloque por bloque está en la página de la versión v0.21.3, y el diff de la ventana está en v2026.9.11…v2026.9.14.

Qué deberías hacer

Las instalaciones manuales se actualizan con un solo comando:

hermes update

Docker y los entornos gestionados se reconstruyen desde el nuevo tag:

docker pull nousresearch/hermes-agent:v2026.9.14

Si tus sesiones solían morir después de que el escritorio despertara, esta actualización merece la pena tomarla primero. Si nunca morían, tu patrón de uso simplemente se libraba de la ventana concurrente — la actualización es igual de segura.