Session Storage Recovery

What to do when Hermes stops writing and says another process still holds an old copy of the session database's write-ahead log, and why nothing is lost.

Hermes keeps every conversation for a profile in one SQLite file, state.db, with two sidecar files SQLite manages itself: state.db-wal (the write-ahead log) and state.db-shm. The gateway, the Desktop app, the dashboard, cron and CLI commands can all share it safely. Rewriting the store while another process is writing to it is not safe, so any process still holding the old copy of the log stops writing on purpose and every turn answers with the refusal message. The fix: quit every Hermes process on that profile (hermes gateway stop, quit the Desktop app, hermes dashboard --stop), run hermes doctor until it no longer lists a holder as PID N (command), then start one process first and send your message again. Do not run hermes doctor --fix while processes are running, do not delete state.db-wal or state.db-shm, do not copy state.db alone, and do not ask the agent to fix it. hermes sessions optimize, optimize-storage and prune now refuse while another process holds the database; --dry-run is never blocked and --force runs anyway. If everything is stopped and the gateway still refuses, inspect the file with hermes sessions recover --source ~/.hermes/state.db --inspect-only.