SecuFocus
BriefAnnouncements

Hermes Agent 0.22.4: check your update channel first

Version 0.22.4 was published on 21 October. Store, CLI and Docker updates differ from desktop installer releases. Automatic history pruning becomes opt-in again.

Generated image: a laptop with an external backup drive, USB flash drive and notebook on a desk in window light.

Generated image · SecuFocus

At a glance

Key points

Hermes Agent 0.22.4 fixes the approval-mode display, WhatsApp re-pairing and plugin setup steps. But the update does not reach every installation method in the same way. Check session retention too: 0.22.3 makes automatic pruning opt-in again, after 0.22.0 enabled it by default.

The fixes published on 21 October

Version 0.22.4 removes the suggestion pills above the desktop composer. Its approval-mode indicator now follows the active profile. A plugin that installs no dependencies no longer asks for empty consent. The dashboard fixes WhatsApp re-pairing after logout.

Version 0.22.3, published earlier that day, includes live MCP call progress, plugin updates offered through hermes plugins update, and steering or editing a queued prompt in Desktop. It also adds a subagent model and provider picker and a /loop countdown in the CLI and TUI. Detailed notes for the cycle are still announced for 0.23.0; that future announcement is not an available release.

Check the setting that can delete your history

Version 0.22.0 enables automatic pruning of ended sessions inactive for 90 days. Version 0.22.3 announces a return to opt-in pruning and a one-time question when disk space runs low. The current documentation confirms that sessions.auto_prune is off by default.

Check your own configuration value: a new default does not prove that an explicit saved choice has changed. If you want to keep the history, verify that automatic pruning is disabled. Before major maintenance, use the documented backup workflow rather than copying state.db alone and leaving out its SQLite journal.

Use the update path for Store, source or container installs

The 0.22.3 and 0.22.4 notes direct Microsoft Store users to Store updates, CLI users to hermes update, and Docker or Hermes Cloud deployments to a new image. They say the desktop app installed from .exe or .dmg installers does not change in these two releases and waits for the next bundled release. Do not try to force the tag’s version number into a package following a different schedule.

Since 0.21.7, source installations from the official repository follow stable releases by default. Tracking every commit on main remains a separate choice. The documentation requires Windows 11 22H2 or later for MSIX and lists Apple Silicon for macOS stable bundles built by default. Linux can run the desktop app from source, but its desktop package is not built by default in this release workflow.

If your installation ran 0.22.1

The 0.22.2 notes say 0.22.1 was built from the wrong commit and could leave the Store app stuck on “Connecting.” Version 0.22.2 restores the intended scope, fixes gateway startup after reboot and addresses long local-model turns.

The same notes warn that sessions used by the 0.22.1 gateway cannot be deleted in 0.22.2. The 0.22.3 and 0.22.4 notes we read do not explicitly resolve that case, so we do not call it fixed. Do not delete SQLite files to bypass the refusal.

Check which model scheduled jobs will follow

The 0.22 cycle also changes model selection for scheduled jobs: unpinned jobs follow the main model at fire time unless a cron-fleet default is configured. A job can retain a pinned model. Before changing the main model, check the jobs that will run unattended, their cost and their data destination.

The release announces automatic reruns when the model was never reached. Current documentation distinguishes that from an interrupted execution or uncertain delivery: some cases remain paused for operator review rather than being retried blindly. A computed result and an actually received message remain separate states. Check recovery with hermes cron doctor and run history, not simply the absence of an alert.

An event burst need not trigger as many runs

Release 0.22.0 documents new webhook options, for requests a service sends when an event occurs. coalesce groups a burst concerning the same object into one run using the latest payload. Choose a key that distinguishes objects: updates to two different tickets should not be merged. This buffer lives in memory, so a hard process kill can lose events still waiting.

A cron_job route triggers an existing job with that job’s model, instructions and delivery destination. It cannot be combined with coalesce or deliver_only. The latter sends a notification without calling the model. An optional mirror_to_session setting can add delivery context to the destination conversation, but the mirror is best-effort rather than a guaranteed history write.

A signature authenticates the webhook sender, not the author of every title or comment it carries. A public ticket remains untrusted content even when its platform signs the request. The documentation specifies a restricted default toolset for these sessions. Do not grant terminal or write access merely because a signature is valid; also check who can supply content, the target profile and the output destination.

External memory and email: two post-migration checks

The 0.22.0 release moves providers including Honcho, Hindsight, Supermemory, Mem0, OpenViking and Holographic into catalog plugins, with migration announced for affected installations. Check hermes memory status and loading errors rather than assuming an old recalled fact proves the provider still works.

The documentation says external memory supplements MEMORY.md and USER.md and can receive conversation turns, including tool output. Pre-send secret scrubbing does not recognize every arbitrary password or unstructured token. Choose the provider’s storage and scope with that data in mind; migration is not a privacy audit.

For the email gateway, the 0.22.0 notes require an authserv_id pin. The documentation names it EMAIL_AUTHSERV_ID and requires the exact identifier written by the receiving server in its topmost Authentication-Results header. Without that pin, messages requiring sender authentication are dropped. Have the mail operator confirm the value and removal of forged headers; do not disable verification merely to restore incoming messages.

Check and explore

Sources for this article

Numbers connect each reference to the passages that use it. Dates show when the documentation was consulted.

This article draws on the sources above. The exercises are for you to try on your devices; SecuFocus does not present them as tests carried out by its editorial team. Interfaces and features can change. Method and corrections.

Cite this article

Keep this reference with the article when you save or share it.