[bug] config agent --agent hermes writes to ~/.hermes instead of $HERMES_HOME, config silently never takes effect

Environment

• CLI: bl 1.13.0
• Skill: 1.13.0
• Node: v22.23.1
• OS: Windows (MINGW64_NT-10.0-26200, git-bash/MSYS2)
• Region: cn-beijing (Token Plan)
• Target agent: hermes

Reproduce

# HERMES_HOME is set (or Hermes uses its Windows platform default)
export HERMES_HOME='C:\Users\<user>\AppData\Local\hermes'

bl config agent --agent hermes --region cn-beijing --key <REDACTED> --model qwen3.8-max-preview

Output:

Warning: Hermes Agent does not support native Windows. Please use WSL2.
Hermes Agent configured successfully.
  Written: C:\Users\<user>\.hermes\config.yaml
  Run `hermes chat -q "hello"` to verify.

Expected

bl config agent --agent hermes should write the model config to the location Hermes actually reads:

• $HERMES_HOME/config.yaml (e.g. C:\Users\<user>\AppData\Local\hermes\config.yaml) when HERMES_HOME is set, or
• Hermes' platform-native default home (%LOCALAPPDATA%\hermes\config.yaml on Windows, ~/.hermes on Linux/macOS).

Hermes resolves its home via get_hermes_home(): override → HERMES_HOME env var → platform-native default (see hermes-agent hermes_cli/config.py).

Actual

The CLI hardcodes ~/.hermes/config.yaml (join(homedir(), '.hermes', 'config.yaml') in the hermes writer) and ignores HERMES_HOME entirely.

On Windows (where Hermes' default home is %LOCALAPPDATA%\hermes) — or on any machine where HERMES_HOME is customized — the config is written to a file Hermes never reads:

• Written to: C:\Users\<user>\.hermes\config.yaml (exists, but Hermes ignores it)
• Hermes actually reads: C:\Users\<user>\AppData\Local\hermes\config.yaml (still has the old model/provider)

Result: the command reports success, but the model/provider change silently does not take effect. In our case Hermes kept using the previous provider (deepseek) and the Bailian models never appeared in the model picker. Only after manually applying the same values with hermes config set model.provider custom / model.default / model.base_url / model.api_key did it take effect.

Additional detail: the same hardcoded ~/.hermes assumption appears in the agent-skill/inventory detection paths for hermes (paths: [join(home, '.hermes', 'config.yaml')]), so bl config agent can also falsely report a hermes agent as "not configured" when HERMES_HOME is non-default.

Full output

Warning: Hermes Agent does not support native Windows. Please use WSL2.
Hermes Agent configured successfully.
  Written: C:\Users\<user>\.hermes\config.yaml
  Run `hermes chat -q "hello"` to verify.
Exit code: 0

Already tried

• Confirmed CLI and installed skill versions aligned at 1.13.0.
• Confirmed $HERMES_HOME is set to C:\Users\<user>\AppData\Local\hermes in the environment.
• Verified Hermes load_config() reads $HERMES_HOME/config.yaml (not ~/.hermes/config.yaml).
• Fixed locally with hermes config set model.provider custom + model.default + model.base_url + model.api_key — takes effect immediately.

Notes

• Frequency: always (deterministic path bug)
• Invoked via: agent (Hermes) on Windows git-bash
• Impact: bl config agent --agent hermes silently no-ops on Windows / non-default HERMES_HOME setups; user believes Bailian is configured but the agent keeps using the old provider.

Start at the bl config agent --agent hermes entry point and inspect the Hermes writer's join(homedir(), '.hermes', 'config.yaml') path construction. Then inspect the agent-skill/inventory Hermes detection paths mentioned in the issue. Done means configuration and detection follow Hermes' override, HERMES_HOME, and platform-default resolution instead of assuming ~/.hermes.