Hermes Agent 0.22.7: more group controls, with access still bounded

The stable tag and the Desktop package have different schedules

The official 0.22.7 release is dated 3 November. For the CLI, it lists hermes update or rerunning the installer. The Microsoft Store follows its own update path; Docker and Hermes Cloud use the announced stable or latest tags. These instructions do not establish that every machine has already received the release.

The same notes say Desktop applications installed from an .exe or .dmg do not change in this release and will update with the next bundled release. A new core tag is therefore not a new app available to every Desktop user. SecuFocus read the release and documents from its exact tag without running the update.

Group rooms expose more of their control and state

The notes announce optional lead routing with a Lead badge in the room header, plus a room purpose and shared notes. They also add scheduled jobs that post into groups and a single-column layout showing each member’s live state.

For a regularly used group, the useful choice is to define who leads the conversation and what should arrive in the room rather than multiplying automated messages. That is our recommendation from the announced features. We did not create a group or a scheduled job for this article; release notes are not a message-delivery test.

• Profiles, shared gateways and task controls↗

See startup progress and failed-update output

The release announces pinned Kanban boards as quick-switch tabs, TeX labels and Mermaid diagrams rendered through Pele. It also adds an update error box with operation output and a reporting link, plus a visible step and elapsed time during Start in Web Access.

Clearer startup state helps you decide whether to wait or investigate an error. It proves neither external reachability nor appropriate protection of the web service. Preserve useful output before retrying, without copying secrets into a report.

• Webapp access precautions in version 0.22.6↗

Shared Telegram and Slack silence are specific choices

For a Hermes Cloud instance using Team Gateway, the tagged documentation describes linking your Telegram account to the shared bot. When Nous Portal manages identities, linking starts from the agent in the Portal; otherwise, the Telegram card supplies the message to send to the bot. Do not assume every instance must run its own direct bot connection.

The same page says that allowing direct connections through the direct-platform opt-in setting keeps a connection active and prevents the instance from sleeping. Check that trade-off before changing the setting; we linked no account and measured no hosting cost.

In Slack, thread_followup_silence is optional and off by default. It lets a silence token stand on unaddressed replies in a channel thread. Direct messages, including group DMs, mentions of the bot and channels without threads retain the usual notice. This does not mean the bot stops reading or answering every message in a room.

The tag’s Mattermost procedure also addresses an identity pitfall: the allowed-user list expects the person’s ID, not their @username or the bot’s ID. One documented method is to open /api/v4/users/me in a browser signed in with the human account. Do not obtain that identity from a request authenticated with the bot’s token. This is a procedure correction, not a new integration; we have changed no permissions.

Daybreak does not admit an unapproved account

The tagged documentation describes agent.daybreak for the ChatGPT/Codex subscription provider. The switch appears only for models the signed-in account’s catalog lists as Daybreak-eligible, and each request checks eligibility again. An unlisted model, an account without access or an unreadable catalog results in a standard request. Approval comes from OpenAI, not from this Hermes setting.

The documented scope is your own Desktop, TUI and CLI chats. Messaging platforms, hosted rooms, A2A peers, third-party integrations, editor clients, cron jobs and subagents are excluded from that request. API-key routes and the optional codex_app_server runtime do not receive it either. This reading verifies neither your eligibility nor a live call’s behaviour.

• A listed model does not grant every permission or quota↗

Optional dependencies and plugins have separate boundaries

The package-manager document in this tag allows persistent exclusion of certain optional tools or Python extras outside all. An explicit opt-out needs an explicit opt-in to reverse it; a dependency still required by another extra may remain. Do not remove a component by name alone without checking which workflows need it.

It also distinguishes requires_hermes from a Python hermes-agent requirement: their version comparisons differ, and either can prevent an incompatible plugin from loading. These admission checks are not a code audit. New catalog pins still need qualification; they are not features installed by default with the core.

The dashboard does not trust just any local port

The 0.22.7 tag’s document restricts browser CORS grants and WebSocket connections to admitted origins, including the loopback origin on the port actually bound. Another local page on 5173 or 5174 does not automatically gain that access. A Desktop development backend can also admit its own renderer’s exact origin without trusting all development ports.

If a local proxy rewrites Host to the backend address, its exact origin, scheme, host and port, must be set in dashboard.public_url, or webapp.public_url for the Webapp. A port forward that preserves the page’s origin follows a separate documented case. Do not work around a rejection by allowing every origin; have the access path checked. Packaged Desktop using file:// retains its native path and authentication check.

We compared this documentation with the origin guard in the tag’s code, without starting a server or attempting an attack. That establishes the rule’s presence in this version, not a guarantee that a deployment, its proxy or its authentication is correctly configured.

A migration can finish while leaving an optional feature out

The 0.22.7 tag document describes carrying Python extras from an old venv into the first PM migration. If a carried extra can no longer be built, the manager can install everything else while reporting and recording its omission. A completed update therefore does not prove all previous optional features are still available. Read the warnings before relying on Matrix or another affected component.

The code distinguishes that build failure from a temporary download or tooling problem: in the latter case, it fails before publishing the new selection so it can retry the migration later. An explicitly requested extra also remains blocking if it cannot be built. An omitted feature must be added back explicitly once the cause is fixed; do not replace that diagnosis by deleting parts of the Python environment.

For PM’s supplied Linux interpreter, the tag code also falls back to an existing GCC or G++ when the recorded Clang is missing, while preserving explicitly set compiler choices. On macOS, it supplies a default archiver path. Required native build tools are still needed. We read these exact-tag documents and modules without migrating an installation, building a package or changing K-Agent.

Plugin admission warnings still need review

The catalog rules in the 0.22.7 tag distinguish failures from warnings. Replacing core functions or bypassing admitted Desktop surfaces can fail admission. Raw calls to the window.hermesDesktop native bridge and some access to the application’s internal markup instead produce review warnings. The document also asks reviewers to read warnings about undocumented modules and private methods.

Passing without a failure therefore does not mean the plugin is isolated. The tag’s Desktop module describes itself as a review tripwire, not a sandbox. Before enabling a plugin, examine its declared access to files, accounts and remote destinations. This reading validates no particular plugin; SecuFocus ran neither an installation nor an admission check.

A command warning is not proof of safety

The tag’s security document flags invisible or bidirectional Unicode characters and variation selectors not following an emoji in commands submitted for approval. It retains exceptions for legitimate emoji sequences. This sends a command through approval controls; it does not guarantee recognition of every dangerous command.

The 0.22.7 notes leave a fuller inventory to 0.23.0. Current documentation may already describe main after this tag. This page therefore separates a release announcement, documented behaviour and executed testing; it does not claim to have validated every catalog plugin.