GitHub Repo
Hermes Agent fixes regression rejecting valid configuration keys, downgrades some typos to warnings
A main-branch fix restores writes for configuration keys absent from the defaults but still read at runtime. The trade-off is that some typos now trigger only warnings, so deployment scripts must separately verify that settings take effect.
Hermes Agent merged a configuration-writing fix on September 17, preventing the CLI from rejecting valid settings, including speech service providers and skill creation prompts, simply because they lack default values. The update is on the main branch and primarily concerns deployments that track the development branch and configure agents through scripts. [Fix PR](https://github.com/NousResearch/hermes-agent/pull/114226)
The problem arose because the validator treated `DEFAULT_CONFIG` as a complete specification. Some settings intentionally have no defaults so the system can distinguish whether a user has explicitly made a choice. A September 15 change replaced warnings for unknown subkeys with write rejections, causing valid settings to fail as well. The reporter checked 237 resolvable paths in an existing list and found that 164 would be rejected, along with 11 affected entries in the example configuration file. These findings apply to a specific version and do not mean every installation is affected. [Issue report](https://github.com/NousResearch/hermes-agent/issues/114107)
The affected settings span speech, browser, scheduling, and display options. For teams that automatically provision multiple agent environments, an update could cause the same configuration script to stop midway, leaving environments only partially configured. This deployment risk is inferred from the failure behavior; the report did not quantify the number of machines actually affected.
After the fix, unregistered keys such as `stt.provider` can be written, accompanied by a warning. Writes are still rejected only for paths with a verifiably misplaced prefix that resolve to a known setting when that prefix is removed. The official documentation now describes this behavior to help deployment operators avoid mistaking a general warning for a setting that has failed to take effect. [Configuration documentation](https://hermes-agent.nousresearch.com/docs/user-guide/configuration/)
The trade-off is that typos within the same section are also accepted. For example, `agent.max_turnz` receives only a suggestion for a similarly named setting. In engineering terms, a script completing successfully proves only that the data was saved, not that the agent adopted the intended value. Deployment tests should therefore verify both configuration readback and actual functionality. Reading a setting back may still return only the value stored in the file; functional testing is needed to confirm that the configuration has taken effect. [Behavioral trade-off](https://github.com/NousResearch/hermes-agent/pull/114226)
[The PR author reported](https://github.com/NousResearch/hermes-agent/pull/114226) that 299 relevant tests passed and four Windows-only tests were skipped, but this article did not independently rerun them. At the time of verification, the latest official release tag was still the September 14 version, so the main-branch fix should not be assumed to have reached container or cloud deployments. Operators should check whether their deployed commit includes `2cf1351`, retest the configuration steps that previously failed, and confirm that error messages are not being filtered out of deployment logs. [Release status](https://github.com/NousResearch/hermes-agent/releases/tag/v2026.9.14)