Hermes Agent v0.21.3: Remote Desktop and state.db Reliability Updates

Hermes Agent v0.21.3, tagged v2026.9.14, is the current v0.21 patch release. It fixes remote Desktop and cloud sign-in sessions that could expire during refresh bursts, and it stops long-lived processes from leaking duplicate state.db writer handles. It follows v0.21.2's wider session-database reliability campaign and the original v0.21.0 Pantheon release, which introduced built-in Bot Mode, peer messaging, cron continuity, live subagent steering, and Desktop browser control. If you use a remote backend, several profiles, or long-running gateways, the patch fixes matter more than the feature headline.

v0.21 patch timeline: which update matters?#

The v0.21 line now has three operationally distinct milestones. Use the newest patch rather than stopping at the original Pantheon tag.

v0.21.3 (v2026.9.14): remote sign-in and long-lived process fixes#

This is the current patch for remote Desktop and cloud users. Two fixes are especially important:

• Refresh bursts no longer revoke remote sessions. Desktop wake-up can trigger several status and token-refresh requests at once. Hermes now coalesces requests carrying the same rotating refresh token, preventing a valid burst from looking like token reuse. Slow identity-provider refresh work also runs off the event loop, so /api/status is not frozen by the refresh.
• Long-lived processes reuse the tracked session-store handle. Gateway, Dashboard/Desktop backend, ACP, and CLI readers attach read-only where appropriate, while in-process writers share the registry handle. This removes the healthy-topology warning that reported an increasing number of live SessionDB handles.

Read the official v0.21.3 release notes for the exact patch scope. The same release window also contains reasoning-effort controls, OpenRouter OAuth PKCE, HEIF/HEIC/AVIF image decoding, MCP OAuth issuer binding, and further multiplexed-profile isolation work, but the official note intentionally defers the complete feature narrative to v0.22.

v0.21.2 (v2026.9.11): the state.db reliability campaign#

v0.21.2 addressed session-store failures reported after v0.21.0. The practical changes are:

• background components stop opening competing writers against the root database;
• healthy WAL databases recover from transient WSL2, ZFS, close-race, and journal-mode conditions more safely;
• damage limited to the FTS search index degrades search instead of classifying the transcript store as corrupt;
• one malformed timestamp or marker row no longer kills session lists, exports, or insights;
• session lookups and Desktop startup stay within the owning profile instead of scanning or binding another profile's database;
• read-only opens no longer take a write lock when no write is needed.

If your symptom is missing sessions, a database-lock warning, a failed session list, or suspected corruption, use the memory and session troubleshooting guide before deleting or replacing state.db. Preserve the entire Hermes home, confirm the active profile boundary, and prefer the built-in diagnostic and backup paths over ad hoc SQLite surgery.

v0.21.0 (v2026.8.31): the Pantheon feature release#

The original release remains the feature milestone: Bot Mode, durable peer messaging, cron continuity, live subagent steering, Desktop browser control, MCP management, and stronger approval and secret boundaries. The sections below explain those features. The patch releases do not change the core positioning; they make the long-running and multi-profile runtime safer.

Should you update now?#

Update now when any of these are true:

• Desktop connects to a remote host or cloud agent;
• a dashboard session signs out after sleep, reconnect, or a burst of refreshes;
• the gateway, Dashboard, ACP server, or several profiles share one installation for long periods;
• you saw state.db lock, WAL, FTS, malformed-row, or cross-profile session symptoms on v0.21.0 or v0.21.1;
• you deploy the official Docker image or maintain a tagged hosted installation.

For a low-risk update, create a Hermes backup, update through the method that owns your installation, run hermes doctor, confirm the active version, open the Dashboard privately, reconnect Desktop, and perform one real gateway or scheduled-delivery test. A green version string is not proof that the remote WebSocket, profile routing, session store, and destination delivery all work.

What changed in Hermes Agent v0.21#

Bot Mode is now a built-in agent workspace#

Bot Mode turns profiles into named Bots inside Hermes Desktop. Each Bot has its own profile-backed configuration, model, instructions, memory, skills, tools, credentials, and chat history. The new shared roster and group chats let a user mention multiple Bots in one room without collapsing their state into one generic assistant.

That boundary matters. A Bot is not a temporary subagent and Bot Mode is not a separate hosted runtime. It is a visual operating layer over durable Hermes profiles. The machine that owns each profile still owns its files, credentials, gateway, and uptime.

The practical workflow is straightforward:

1. Create a specialist Bot in Hermes Desktop.
2. Give it a narrow role and only the skills and tools it needs.
3. Use a group when several specialists need shared conversation context.
4. Keep high-risk credentials in a separate profile instead of one all-powerful Bot.
5. Inspect the canonical Bot Chat when a routine or peer message needs an audit trail.

hermes peer makes handoffs durable#

hermes peer lets one Hermes agent message another by handle across profiles and gateways. Replies land in canonical Bot Chats, so a research-to-writing or monitoring-to-operations handoff is inspectable rather than fire-and-forget.

This is different from subagent delegation. A subagent is a bounded child run created for parallel work. A peer is another durable agent identity with its own profile and conversation. Use delegation to split one mission; use peers when long-lived specialists need to communicate.

Cron jobs can remember previous runs#

The most important automation change is continuity. v0.21 cron agents can load and update persistent memory, continuity=true can carry one run's output into the next, and each job can use a durable notepad. A monitor can therefore remember what it already reported rather than sending the same item every morning.

Monitor mode also supports hash-suppressed change detection: when the deterministic input has not changed, the job can skip the LLM call entirely. That is both quieter and cheaper. The AI agent cron jobs guide explains lifecycle states, delivery errors, timeouts, and safe recovery; the scheduling tutorial covers creation and verification.

Continuity does not make reruns exactly once. For a job that publishes, charges, sends, or deletes, still reconcile the external target before replaying an unknown or timed-out attempt. Memory helps the next run reason about history; it does not replace idempotency.

Running subagents can be steered or stopped#

delegate_task now supports live orchestration. A parent can list running children, steer one with a course correction, or stop it and retain the partial result. Delegations can also request JSON-schema validation and expose per-child cost in their results.

This closes a common gap in parallel agent work: discovering halfway through a long task that the child is solving the wrong problem. The new controls are useful only when responsibilities are still separated cleanly. Give each child one deliverable, avoid having two agents edit the same file, and validate the merged result in the parent.

Desktop, browser, MCP, and CLI upgrades#

The Desktop browser is now an action surface#

The in-app browser is no longer view-only. Hermes can navigate, click, and read inside the Desktop browser, while pages can still be opened in the system browser. This creates a visible browser-control path for docs walkthroughs and web-app debugging.

It does not remove anti-bot limits or magically import every authenticated browser session. Choose the source according to the job: use search or extraction for public reading, an API for stable structured access, and a real browser profile for authenticated action. The browser automation troubleshooting guide covers CDP, Docker, saved profiles, and verification.

MCP management becomes a command center#

Desktop now combines configured MCP servers and the catalog in one page. The release adds paste/import flows, background health checks, schema-token and 30-day usage views, and confirmation-gated hermes:// install links.

Health visibility is not a permission boundary. Continue to review the server, transport, scopes, and exposed tools; store tokens in the approved secret path; and reload or restart after configuration when required. Use the MCP setup guide for connection mechanics and MCP security guide for least-privilege decisions.

CLI status is more operational#

The CLI gains a fuzzy command palette on Ctrl+P, searchable model selection, richer /status output, configurable live cache-hit/latency/tokens-per-second fields, session pinning, and a global emergency stop. These additions make context, approvals, and performance easier to inspect without leaving the terminal.

Security changes worth checking after update#

v0.21 adds mandatory write approval for protected instruction surfaces such as AGENTS.md, skills, and memory stores. The release also expands redaction across .env reads, terminal errors, checkpoints, ACP logs, and SSH-target logging; adds destructive-command coverage on Windows; scans plugin installs; and gives macOS Desktop a stable TCC signing identity so permission grants can survive updates.

These are defense-in-depth changes, not permission to run unknown skills or MCP servers with broad credentials. Review the Hermes security hardening guide, keep profile permissions narrow, and verify approval prompts on the operating surface you actually use.

How to update safely#

Back up durable state before a large release, then update through the installation path you actually use. For a normal CLI installation:

hermes update
hermes config migrate
hermes doctor
hermes --version

After updating, test the exact critical path rather than stopping at a version string:

• Open Desktop and confirm the intended backend and profile.
• Run one harmless Bot or peer message and inspect the canonical chat.
• Trigger one non-consequential cron job and verify run history plus delivery.
• Open the MCP page and check health before executing a tool.
• Use the browser on a harmless public page before relying on an authenticated workflow.
• Confirm protected-file writes produce the expected approval.

If the update fails, use the safe Hermes update guide and update troubleshooting article. Do not repeatedly rerun an updater over uncommitted local source changes.

What v0.21 does not change#

Pantheon makes multi-agent work easier to operate, but it does not remove infrastructure ownership:

• Bot Mode does not provide a cloud computer.
• A saved routine cannot run while its only host is truly off.
• Peer messages do not merge credentials or files between profiles.
• A healthy MCP connection does not prove the server is trustworthy.
• Browser control does not guarantee access through anti-bot or login barriers.
• Persistent memory does not make side effects exactly once.

If you want to own the runtime, the self-hosted versus hosted AI agent comparison maps the operational responsibilities. If you want browser/mobile access, connected channels, and managed uptime without maintaining the VPS and gateway yourself, compare the FlyHermes managed path.

Who should update now?#

Update promptly if you use Desktop Bots, recurring monitors, delegated parallel work, MCP fleets, or the Desktop browser. Security-sensitive installations also benefit from the protected-file approval and redaction work.

For a production gateway, treat the update as an operational change: back up state, read the release notes, preserve local modifications, update during a recoverable window, and verify each connected channel. A release with thousands of merged changes deserves a real smoke test.

Bottom line#

Hermes Agent v0.21 turns separate agent features into a more coherent operating system. Bots have durable identities, peers can hand work across profiles, cron jobs can carry state, subagents can be corrected mid-flight, and Desktop exposes browser and MCP operations directly. The value is not “more agents.” It is clearer ownership, continuity, and observability around the agents already doing work.

Where to inspect Pantheon after updating#

Open the Hermes Dashboard and Web UI to inspect profiles, Bot-owned sessions, cron continuity, resource warnings, MCP state, and automation history. Use its embedded TUI Chat when a workflow needs slash commands or approval prompts, and use Kanban for task/worker visibility. The dedicated Bot roster, group chats, multi-connection registry, and chat-first workflow remain Desktop surfaces.