Hermes Agent
Hermes replaces 1.3-second SQLite patience with time-based write budgets
A closed Hermes Agent patch says nine concurrent processes sharing a 10.8 GB state database could lose turns when legitimate write locks lasted beyond roughly 1.3 seconds. The change gives routine writes 20 seconds, transcript-critical writes 60 seconds, and adds explicit WAL-refusal handling.
NousResearch/hermes-agent PR #74480 is the inspected primary source: “fix(state): time-based write-lock patience so busy sibling processes can't destroy turns.” The two related records below were inspected as supporting context, not treated as independent confirmation.
The facts
- NousResearch/hermes-agent PR #74480 was created 2026-07-30T00:44:13Z and was closed at inspection; its title is “fix(state): time-based write-lock patience so busy sibling processes can't destroy turns.” - NousResearch/hermes-agent issue #74478 was created 2026-07-30T00:41:46Z and was closed at inspection; its title is “[Bug]: Turn aborted as session_persistence_failed / SessionDB init disabled when a sibling process holds the state.db write lock for a few seconds.” - NousResearch/hermes-agent PR #74485 was created 2026-07-30T00:55:11Z and was open at inspection; its title is “fix(state): configurable journal_mode + WAL-refusal detection cluster (salvages #68912, #57918, #46865, #55322).” - The repository reported 222348 stars, 26215 open issues, default branch main, and last push 2026-07-30T01:00:20Z. - The latest tagged-release baseline checked was v2026.7.20 published 2026-07-20T18:35:55Z.
What changed
NousResearch/hermes-agent PR #74480 reports: Symptom Users still hit destroyed turns on current installs: No reply: the turn was stopped because session storage could not be written (the transcript would have been lost on restart). Check disk space / permissions for the state DB, then send your message again. and, separately, whole runs silently lose persistence at startup: Observed 2026-07-29 on a 10.8 GB state.db shared by 9 concurrent hermes processes (gateway + CLI worktree agents): bursts of Session DB append_message failed: database is locked in errors.log at 12:50–12:57 and ~19:50. Fixes #74478 Root
NousResearch/hermes-agent issue #74478 reports: Symptom Even on a current install, turns still die with: No reply: the turn was stopped because session storage could not be written (the transcript would have been lost on restart). Check disk space / permissions for the state DB, then send your message again. and separately, new CLI sessions start with persistence disabled: Observed 2026-07-29 on a 10.8 GB state.db shared by 9 concurrent hermes processes (gateway + CLI worktree agents). errors.log shows bursts of Session DB append_message failed: database is locked at 12:50-12:57 and ~19:50. Root cause
NousResearch/hermes-agent PR #74485 reports: Summary database.journal_mode in config.yaml is now the canonical, honored operator setting for every Hermes SQLite opener, and the WAL fallback path detects all three real-world refusal shapes (raising, silent no-op, and disk-I/O) without ever live-downgrading an on-disk WAL database. Consolidated salvage of four contributor PRs on the same WAL-vs-filesystem class: #68912 (@smfworks), #57918 (@LavyaTandel), #46865 (@connorblack), #55322 (@Sahil-SS9). Closes #57820, closes #68545, addresses #71498 / #55305 / #46797. Changes hermes_state.py: resolve_journal_mode() reads database.journal_mode (wal/delete, invalid → wal) and apply_wal_with_fallback() honors it under all existing guards (never downgrades an on-disk WAL
Why it matters
A database can be healthy while a concurrency policy destroys the work it stores. Transcript writes need patience tied to operator impact and an error that distinguishes contention from disk damage. This is an operator boundary: persisted state, execution ownership and visible controls must describe the same event. A workaround that broadens access, deletes state or hides the symptom would trade a visible defect for an unmeasured one.
Current
The primary record was closed when captured on 2026-07-30. The release baseline was v2026.7.20 published 2026-07-20T18:35:55Z. Current repository metadata, pull requests, issues, release records, Google News discovery, Hacker News discovery, Lobsters, Metamesh and the rendered ClawCharts row were checked. ClawCharts selected the subject; it did not prove the claim.
Evidence
The primary URL is https://github.com/NousResearch/hermes-agent/pull/74480. Supporting records are https://github.com/NousResearch/hermes-agent/issues/74478 and https://github.com/NousResearch/hermes-agent/pull/74485. Their source bodies, timestamps and states were captured in the daily evidence bundle. Test counts, reproductions and deployment observations remain attributed to their authors unless explicitly identified as independently rerun.
Source boundary
Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Issue closure would not by itself prove a deployed fix. Search residue, package mirrors and historically published source spines were excluded.
Operator take
Watch lock-hold duration and mixed-version processes, then verify that delayed writes survive without hiding genuinely stuck maintenance. Patience is a budget, not permission to wait forever. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently after intervention.
Caveat
Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.
Source inspected; source state, environment and release boundary remain explicit.