Hermes Agent community reports Matrix encryption state conflict that may prevent later DMs from decrypting across processes

A reliability report concerning multi-process encryption state has surfaced in Hermes Agent’s Matrix integration. On October 18, a user reported that if hermes send sends a message using the same configuration profile while the gateway is running, subsequent bot direct messages may fail to decrypt. A subprocess launched by the agent itself could also trigger the issue. The reported environment was Hermes 0.22.2. The report includes reproduction steps and sender-side logs, and the issue remains open. Source: issue report

Understanding the issue requires distinguishing between Matrix’s two layers of encryption state. The official documentation explains that Olm is used for encrypted communication between devices, while Megolm handles room messages; new Megolm session keys must be shared through a secure channel between devices. In other words, successfully sending a room message to the server does not prove that the receiving device has obtained the key needed to decrypt it. Source: Matrix guide to end-to-end encryption

According to the reporter’s code analysis, the command-line path creates a separate client that shares the device identity and crypto.db with the gateway. After the second process advances and writes back Olm state, the gateway may still use an older in-memory cache to share room keys, leaving the database and process state out of sync. Notably, the sender still logs the key share as successful, which could cause monitoring to miss the failure on the receiving end. However, this root-cause interpretation has not yet been independently confirmed by maintainers, and receiving-side debug logs are not available. Source: root-cause analysis

This has practical implications for teams using chat platforms as agent interfaces: health checks should cover whether messages are readable by recipients, and teams should check which process owns the continuously changing encryption state. The reporter suggests routing external messages through the running gateway and, as a temporary measure, avoiding a separate encryption client that uses the same device. Restarting the gateway restored subsequent direct messages in the reported case, but that does not mean older messages will necessarily be recovered. Next, watch for whether a fix adds inter-process forwarding, state locking, and race-condition tests, as well as which deployment scenarios are covered by a release. Source: proposed fix and temporary workaround