Tienes tres perfiles del mismo bot en una sola máquina: uno vigila un canal de soporte, otro publica un resumen diario y un tercero patrulla en segundo plano. El lunes añades el cuarto y no aparece por ninguna parte en la lista de Bots del escritorio: al lado, el estado del gateway dice detenido, así que reinicias el gateway entero y de paso interrumpes las dos instancias que sí estaban trabajando. Pero lo que de verdad te inquieta es otra cosa: esos perfiles, compartiendo máquina, ¿ven en silencio las credenciales, la memoria y las sesiones de los demás?

v0.21.2 responde a las dos cosas. No hay ninguna función estrella: los dos objetivos son de lo más terrenal — que cada perfil de la máquina guarde lo suyo, y que el escritorio deje de abrir un backend por cada perfil.

Un proceso de gateway, tres conjuntos de bots

Empecemos por lo básico: un perfil es, en la práctica, una instalación de Hermes independiente, con su propia configuración, sus propias credenciales, su propia memoria y su propio historial de sesiones. Para que varios perfiles en una misma máquina no necesiten cada uno su gateway, Hermes trae un multiplexor: un único proceso de gateway que aloja a la vez los bots de varios perfiles. Compartir ese proceso es justamente la ventaja, y justamente el riesgo: todo lo que se resuelva “de forma global” dentro del proceso puede filtrarse de un perfil a otro.

La forma habitual de estas instalaciones es un perfil principal más algunos perfiles secundarios, compartiendo proceso y parte del estado en tiempo de ejecución. Si quieres organizar tu máquina así, la guía de perfiles multi-instancia explica qué conviene compartir y qué debe quedarse separado.

v0.21.2 (etiqueta v2026.9.11, publicada el 11 de septiembre de 2026, con el apodo oficial “The state.db Patch Release”) es la versión de parches que sigue a v0.21.1, y no es pequeña: desde v0.21.1 acumula 947 commits no de merge, 1.869 archivos modificados (+182.504 / -15.564) y 312 pull requests fusionadas de 140 contribuyentes. La lista completa por bloques está en la página de la versión v0.21.2; aquí van las partes que no tienen nada que ver con state.db pero cambian tu día a día.

Siete fugas, cerradas de una vez

Lo que hay que temer en una instalación multi-perfil no es un fallo, sino un sangrado silencioso: que un perfil use los permisos, los secretos o los archivos de otro y todas las pantallas se vean normales. Siete pull requests de esta versión apuntan exactamente ahí:

PR	Qué se cruzaba de un perfil a otro	Comportamiento ahora
#107616	Los bots de un perfil secundario heredaban la allow-list del perfil predeterminado; la lista de permisos se resolvía entre perfiles	cada perfil resuelve su propia allow-list
#107617	Los adaptadores podían enviar credenciales al host del perfil predeterminado	las credenciales viajan con el perfil al que pertenecen
#107630	Los servidores MCP por stdio recibían los secretos del vault del perfil predeterminado	solo reciben los secretos del perfil actual
#107609	La entrega de MEDIA: podía arrastrar el .env, el auth.json o el state.db de otro perfil	la entrega queda limitada al perfil que la inicia
#107620 / #107626	Las llamadas de vuelta de Feishu drive, y las respuestas de webhook en una ruta propia de un perfil, podían acabar en otro perfil	las llamadas y las respuestas se quedan en el perfil enrutado
#107611	Un perfil secundario podía tomar prestado el token bearer de Nous de un perfil hermano desde la memoria del proceso	los tokens ya no se reutilizan entre perfiles

#107616 merece una frase aparte. La allow-list es lo que define el límite de permisos de un bot, y antes se resolvía contra el perfil predeterminado: todo lo que habías abierto en el perfil principal lo heredaba el secundario. Con dos bots haciendo trabajos que no tienen nada que ver, eso significaba regalar los permisos del principal al otro. El contexto de este caso está en el artículo sobre la allow-list por perfil.

Leyendo la tabla completa se saca una prueba útil: todo lo que se comparte “a nivel de proceso” —la memoria interna, el vault, los hosts de los adaptadores, los canales de entrega— ha sido históricamente el punto débil del modo multi-perfil. Esta tanda no parchea caso por caso: devuelve cada punto de resolución al límite del perfil.

El escritorio deja de abrir un backend por perfil

El segundo bloque es el arranque del Bot Mode del escritorio, y el síntoma se veía a simple vista. Antes, al arrancar y en cada tick del roster, el escritorio generaba o marcaba un backend por cada perfil; pasar el ratón por la lista de Bots generaba un backend por cada fila; cambiar de perfil podía generar backends primarios duplicados. Tantos perfiles tuvieras, tantos múltiplos de procesos backend acumulabas, y los sobrantes se peleaban por el mismo gateway.

Esta versión toca tanto la ruta de arranque como la de renderizado de la lista: #108069, #108107, #108118, #108134, #107969, #108112. El resultado práctico es que la escena del principio ya no ocurre: añadir un perfil no obliga a reiniciar el gateway de madrugada, y en la lista de Bots dejan de aparecer entradas fantasma con un estado dudoso.

Las correcciones de “esto no tiene sentido”

Más allá de esos dos bloques, la versión limpia un conjunto de comportamientos pequeños que llevaban mucho tiempo molestando en silencio. Ninguno es espectacular por separado; juntos son una pared con la que tropiezas cada día.

Cron. Un “ejecutar ahora” fuera de la hora en punto ya no cancela la siguiente ejecución programada (#106306); una ejecución manual que mataste ya no bloquea la siguiente franja de cinco minutos (#106733); una tarea convertida de puntual a recurrente sigue disparándose (#106532); una tarea sin modelo fijado se ejecuta con el modelo capturado al crearla (#106499); y hermes profile create --clone-all ya no se lleva consigo las tareas cron (#106478). Esta última es la que más importa en multi-perfil, porque clonar un perfil suele ir de reutilizar configuración, no de ejecutar la misma tarea programada una segunda vez en el segundo perfil.

Kanban. kanban promote ahora rechaza una tarea padre sin terminar (#106550) y kanban_request_review rechaza un perfil revisor desconocido (#106547). Ambas convierten “aceptar en silencio una entrada mala” en “rechazarla con claridad”.

Herramientas y memoria. Cuando un servidor MCP por stdio muere a mitad de llamada, la llamada a la herramienta ya no se repite (#106546) —repetirla significa que una escritura que quizá ya se ejecutó ocurre por segunda vez, y eso hace que este arreglo valga mucho—. Una revisión en segundo plano compuesta solo por skills ya no puede borrar entradas de memoria (#106310); la memoria mem0 ya no pierde turnos largos (#106542); tool_search devuelve vacío antes que cinco herramientas sin relación que solo comparten una palabra (#106676); el sudo NOPASSWD remoto ya no dispara un aviso de aprobación (#107939); y la lectura de RSS y Reddit ya no viene activada por defecto (#105873).

Actualizaciones y cuota. La comprobación de actualizaciones ahora consulta la API de GitHub una vez al día en lugar de hacer un git fetch cada 30 minutos (#107648); hermes update dice el motivo real de un fallo y ya no se queda colgado en un fetch atascado (#108053).

Proveedores y enrutado. /model y el enrutado automático auxiliar no facturan a un proveedor que no elegiste (#107366); Hermes nunca cambia solo a un proveedor para el que no tienes credenciales (#107281); Bedrock Guardrails surte efecto (#107815).

Caché. Cambiar entre el escritorio y la TUI ya no reconstruye el system prompt, así que ya no rompe la caché de prompt (#105844): un ahorro real para quien salta entre las dos interfaces todo el día.

Qué deberías hacer

Actualizar es un solo comando:

hermes update

Después conviene confirmar unas cuantas cosas:

• Si configuraste una allow-list de permisos en una máquina multi-perfil, ahora cada perfil resuelve la suya (#107616): comprueba que las listas de los perfiles secundarios son las que realmente quieres.
• Si dependías de hermes profile create --clone-all para traerte las tareas cron, ahora tendrás que recrearlas a mano (#106478).
• Si quieres seguir usando RSS o Reddit como fuentes de contenido, actívalos explícitamente: por defecto están apagados (#105873).
• Si una tarea programada no tiene modelo fijado, ahora se ejecuta con el modelo capturado en el momento de crearla (#106499).
• La comprobación de actualizaciones va una vez al día (#107648): no lo interpretes como que se ha vuelto más lenta, simplemente dejó de hacer fetch cada media hora.

Una línea más sobre el trabajo de state.db, que no es el tema de este artículo: v0.21.0 reescribió el manejo de conexiones del almacén de sesiones y eso dejó el state.db frágil en algunas instalaciones; v0.21.2 cerró esa clase de problemas. Lo tratamos por separado: los detalles están en bloqueos y escritores de state.db.

Conclusión

v0.21.2 es un parche de endurecimiento de manual: ninguna función que presumir, con 947 commits no de merge y 312 pull requests fusionadas dedicadas casi todas a recuperar límites. Si usas un solo perfil, el cambio más visible será probablemente que el escritorio deja de arrastrar un montón de backends fantasma. Si usas varios perfiles en una máquina, la versión importa mucho más: desde la allow-list de permisos, los secretos del vault y los hosts de credenciales hasta los tokens dentro del proceso, siete fugas entre perfiles se cierran de golpe.

Los perfiles múltiples dejan de ser una configuración que “funciona, pero nunca estás del todo tranquilo”: cada perfil guarda lo suyo y el escritorio abre solo los backends que necesita. Eso es lo que arregla esta versión.