Summary
cli.py now stores/reads prefill config under agent.prefill_messages_file, but the canonical config schema and the gateway/cron loaders still use the root-level prefill_messages_file key. As a result, a valid ~/.hermes/config.yaml entry can work in gateway/cron paths while being silently ignored in the standalone CLI.
Affected code
cli.py:249-253 — CLI defaults place prefill_messages_file under agent
cli.py:1735-1738 — runtime only reads CLI_CONFIG["agent"].get("prefill_messages_file", "")
hermes_cli/config.py:610-614 — canonical config schema still exposes root-level prefill_messages_file
gateway/run.py:1071-1085 — gateway still reads root-level prefill_messages_file
cron/scheduler.py:658-660 — cron still reads root-level prefill_messages_file
Why this is a bug
The same config key is interpreted differently across entrypoints:
- gateway/cron accept
prefill_messages_file at the config root
- CLI ignores that same root-level key and only checks
agent.prefill_messages_file
That means a user can have a valid config according to the schema/docs and still lose their few-shot prefill behavior in the CLI with no error.
Minimal reproduction
import tempfile, pathlib, importlib, json, os, sys
sys.path.insert(0, "/Users/genie/.hermes/hermes-agent")
with tempfile.TemporaryDirectory() as td:
home = pathlib.Path(td)
(home / "config.yaml").write_text("prefill_messages_file: prefill.json\n", encoding="utf-8")
os.environ["HERMES_HOME"] = str(home)
sys.modules.pop("cli", None)
import cli
cli._hermes_home = home
cfg = cli.load_cli_config()
print(cfg.get("prefill_messages_file")) # "prefill.json"
print(cfg.get("agent", {}).get("prefill_messages_file")) # ""
Observed in this repo:
- root-level value survives config load
- CLI runtime lookup is empty because it only checks
cfg["agent"]["prefill_messages_file"]
Expected behavior
All Hermes entrypoints should accept the same config location for prefill messages, or the CLI should preserve a backward-compatible fallback from the root-level key.
Actual behavior
A root-level prefill_messages_file works in gateway/cron code paths but is silently ignored by the CLI.
Suggested investigation
Choose one canonical location and normalize consistently during config loading. If agent.prefill_messages_file is the new home, load_cli_config() should still map the legacy root-level key into agent.prefill_messages_file so existing configs keep working.
Summary
cli.pynow stores/reads prefill config underagent.prefill_messages_file, but the canonical config schema and the gateway/cron loaders still use the root-levelprefill_messages_filekey. As a result, a valid~/.hermes/config.yamlentry can work in gateway/cron paths while being silently ignored in the standalone CLI.Affected code
cli.py:249-253— CLI defaults placeprefill_messages_fileunderagentcli.py:1735-1738— runtime only readsCLI_CONFIG["agent"].get("prefill_messages_file", "")hermes_cli/config.py:610-614— canonical config schema still exposes root-levelprefill_messages_filegateway/run.py:1071-1085— gateway still reads root-levelprefill_messages_filecron/scheduler.py:658-660— cron still reads root-levelprefill_messages_fileWhy this is a bug
The same config key is interpreted differently across entrypoints:
prefill_messages_fileat the config rootagent.prefill_messages_fileThat means a user can have a valid config according to the schema/docs and still lose their few-shot prefill behavior in the CLI with no error.
Minimal reproduction
Observed in this repo:
cfg["agent"]["prefill_messages_file"]Expected behavior
All Hermes entrypoints should accept the same config location for prefill messages, or the CLI should preserve a backward-compatible fallback from the root-level key.
Actual behavior
A root-level
prefill_messages_fileworks in gateway/cron code paths but is silently ignored by the CLI.Suggested investigation
Choose one canonical location and normalize consistently during config loading. If
agent.prefill_messages_fileis the new home,load_cli_config()should still map the legacy root-level key intoagent.prefill_messages_fileso existing configs keep working.