When Hermes feels broken, the fastest way to lose time is to treat every symptom like a runtime failure. The current research pack supports a better rule: first decide which lane actually failed, then use the smallest proof or inspection step that can confirm it.
Start by identifying the failing lane
- install or shell path
- model/provider configuration
- session continuity or wrong resume target
- messaging or mention-gating behavior
- approval or authorization posture
- backend or container isolation
Use a fast triage sequence first
- confirm Hermes is actually installed and on PATH
- confirm the expected provider/model pairing is configured
- confirm you are in the expected session
- confirm the surface behavior matches the platform rules
- confirm approval, authorization, or backend settings did not silently change
- use validation and observability helpers when you need proof
- only then choose restart, reconfigure, or rebuild
Short recovery entries that solve a lot of cases
hermes: command not found→ reload shell profiles and inspect PATH first- right model name, wrong behavior → check provider, alias path, and auxiliary behavior
- context looks wrong →
hermes sessions listbefore assuming memory loss - bot seems silent → verify the platform rules before treating it as runtime failure