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.