Hermes Agent 0.21.3 Fixes Session Refresh and state.db Writers

Hermes AgentAI agentAn AI program that performs work steps by itself, for example reading a message, drafting a reply, and recording the result.Open the glossary 0.21.3 was released on September 14, 2026, and teams that use remote Desktop, Cloud, gateway, ACP, or long-running CLI processes should prioritize it. The update fixes two operational paths: remote sessions that can be revoked when concurrent requests refresh a token, and extra writer handles that accumulate on `state.db`. A **refresh burst** is a group of requests that arrive at almost the same time after an access token expires. Without coordination, the first request can rotate the refresh token. Later requests can then reuse the old token and trigger reuse detection, which revokes the full session.

What changed in Hermes Agent 0.21.3?

The [official Hermes Agent 0.21.3 release notes](https://github.com/NousResearch/hermes-agent/releases/tag/v2026.9.14), published on September 14, 2026, describe this version as a patch rollup of about 338 pull requests since 0.21.2. The main purpose of the stable tag is to deliver remote sign-in fixes to Docker images, Hermes Cloud, and hosted deployments.

Area	Before 0.21.3	Change in 0.21.3	Operator impact
Remote-session refresh	Concurrent requests could use an old refresh token after rotation.	Requests with the same token are coalesced into one refresh.	A Desktop wake burst no longer revokes the full session through reuse detection.
Gateway event loop	A slow identity-provider call could block the status endpoint.	Refresh work runs outside the event loop.	Status checks do not wait behind a slow identity provider.
`state.db` access	Some internal paths opened extra writable `SessionDB` handles.	Readers use read-only mode, and writers in one process share a registry handle.	The multiple-writer-handle warning stops on a healthy topology.

The session change comes from [pull request #110061](https://github.com/NousResearch/hermes-agent/pull/110061), merged on September 13, 2026. Its live test reports that the baseline kept only 1 of 4 requests alive during a burst. The new implementation kept 4 of 4 requests alive and reduced four provider calls to one. These numbers come from an upstream reproduction with a stub identity provider. They are not a performance guarantee for every deployment. The database change comes from [pull request #110934](https://github.com/NousResearch/hermes-agent/pull/110934), merged on September 14, 2026. Dashboard, gateway, ACP, and CLI paths that only read data now open the database in read-only mode. Write paths use the shared registry so that one process does not create a new writer connection for the same path.

Does your team need to upgrade now?

**Yes, use a controlled upgrade** if your deployment uses remote Desktop or Cloud, loses sessions after a laptop wakes, runs the gateway and dashboard for long periods, uses ACP, or has shown an `N live SessionDB handles` warning. For a local, single-user installation with no remote login and no database symptoms, schedule a canary in a maintenance window. Do not interrupt active work only because the version number changed. If you do not upgrade, the risk depends on your topology. Remote users can continue to get logged out or lose a session when refresh requests occur together. Long-running processes can continue to open extra writer handles and trigger a precursor warning. [Issue #100896](https://github.com/NousResearch/hermes-agent/issues/100896), published on September 2, 2026, documents four `state.db` corruption incidents in five weeks on one host with multiple writer processes. This is evidence from one deployment. It does not prove that every warning will cause corruption. Rama Digital previously covered the [risk of maintaining `state.db` while the gateway is active](https://ramadigital.id/blog/bug-p1-hermes-agent-0210-maintenance-state-db-gateway-aktif-korupsi). Version 0.21.3 closes the duplicate-writer-handle leak described as a precursor, but an upgrade does not recover a database that is already damaged. You still need a restorable backup and an integrity check.

How do you upgrade Hermes Agent 0.21.3 safely?

1. **Record the current version and symptoms.** Keep the times of remote logouts, `SessionDB` warnings, and gateway status results so that you can compare the canary. 2. **Back up `state.db` while writers are stopped.** Do not depend on one copied file while WAL or another process is active. Test that the backup opens and passes an integrity check. 3. **Select one canary.** Use one non-critical host or profile. Our guide to [selecting a VPS for Hermes Agent](https://ramadigital.id/blog/best-vps-for-hermes-agent) helps you separate host capacity from application faults. 4. **Use the official update path.** The September 14, 2026, release notes specify `hermes update` for Git installations. Docker deployments use `nousresearch/hermes-agent:v2026.9.14`. 5. **Test two scenarios.** Let the access token approach expiry and open several dashboard requests. Run the gateway and dashboard through the canary's normal usage pattern, and check whether the writer-handle warning returns. 6. **Prepare rollback.** Keep the previous version artifact and the pre-upgrade backup. An application rollback does not automatically repair a damaged database. Do not deploy to all hosts at once if you use a cross-VM filesystem or shared storage. The September 14, 2026, release notes also mention a WAL refusal on cross-VM filesystems, but the complete 0.21.x notes are planned for version 0.22.0. Verify storage behavior on the canary before you expand the rollout.

What should you monitor after the upgrade?

Monitor remote sessions, status-endpoint latency, refresh calls to the identity provider, `SessionDB` warnings, and database integrity-check results. Compare each signal with the pre-upgrade baseline. Do not use a dashboard that appears functional as the only success criterion. Set a stop condition. Stop the rollout if sessions are still revoked, writer-handle warnings return, an integrity check fails, or the gateway reports a new database error. If the canary remains stable during its routine usage pattern, continue to the next host in stages.

Hermes Agent 0.21.3 questions and answers

When was Hermes Agent 0.21.3 released?

Hermes Agent 0.21.3, tagged `v2026.9.14`, was released on September 14, 2026, according to the official GitHub release page.

Does this version fix all `state.db` corruption?

There is no evidence that all corruption classes are fixed. The release fixes duplicate writer handles within a process. Historical issues also involve topology, WAL behavior, separate processes, and storage conditions that need separate tests.

Who should upgrade first?

Teams that use remote Desktop or Cloud, long-running gateway and dashboard processes, ACP, or deployments with multiple `SessionDB` writer-handle warnings receive the most direct operational benefit.

What is the largest risk of staying on an older version?

The documented risks are remote-session revocation during a refresh burst and extra writer handles in long-running processes. The size of the risk depends on the deployment topology and request pattern.

Is a restart a sufficient mitigation?

A restart can remove a symptom for a short time, but it does not install single-flight refresh or shared writer-registry behavior. A restart also does not recover a database that is already damaged.

Operational conclusion

Upgrade to Hermes Agent 0.21.3 through a canary now if you use remote sessions or long-running gateway processes. Take a tested backup, use the official tag, monitor refresh and `state.db`, and expand the rollout only if no stop condition occurs.