fix(runtime_provider, model_switch): resolve custom provider key_env from .env file

[franksong2702]

Summary

Named custom providers that declare key_env in config.yaml (e.g. key_env: VOLCENGINE_CODING_PLAN_API_KEY) silently lose their credentials when the key only exists in ~/.hermes/.env.

Three code paths read key_env via os.getenv() / os.environ.get() instead of get_env_value() — which means they only see process-level env vars and miss the .env file entirely. The fallback chain then produces an empty string, and the next fallback is the inline api_key field (also empty for users who migrated to .env). The end result: the provider resolves to "no-key-required" and every /models probe returns 401.

Root Cause

get_env_value() in hermes_cli/config.py reads os.environ first, then falls back to parsing ~/.hermes/.env. Three call sites bypassed this helper:

File	Function	Line	Old code	New code
runtime_provider.py	_get_named_custom_provider	531	os.getenv(key_env, "")	get_env_value(key_env)
runtime_provider.py	_resolve_named_custom_runtime	735	os.getenv(key_env)	get_env_value(key_env)
model_switch.py	switch_model (user provider path)	921	os.environ.get(_kenv, "")	get_env_value(_kenv)

Impact

Any user who:

1. Defines a named custom provider in config.yaml with key_env: SOME_VAR
2. Stores the actual credential in ~/.hermes/.env (the documented approach)
3. Does not pre-load that variable into the process environment

...will experience silent credential loss on that provider. The model switch still appears to succeed (because the validation override at line 1002-1041 catches models declared in the provider's models: list), but:

• /models probes fail with 401
• The validation warning is misleading: "could not reach the API to validate"
• Runtime calls that skip validation (e.g. chat completions) also fail with 401

Reproduction

# config.yaml
providers:
  volcengine-coding-plan:
    name: Volcengine Coding Plan
    base_url: https://ark.cn-beijing.volces.com/api/coding/v3
    key_env: VOLCENGINE_CODING_PLAN_API_KEY
    models: [deepseek-v4-pro]

# ~/.hermes/.env
VOLCENGINE_CODING_PLAN_API_KEY=sk-xxx

# Before fix:
resolve_runtime_provider(requested="volcengine-coding-plan")
# -> api_key = "no-key-required" (15 chars, wrong)

# After fix:
resolve_runtime_provider(requested="volcengine-coding-plan")
# -> api_key = "sk-xxx" (correct, from .env)

Tests

All 207 tests in the relevant test files pass:

• tests/hermes_cli/test_runtime_provider_resolution.py
• tests/hermes_cli/test_model_validation.py
• tests/hermes_cli/test_model_switch_copilot_api_mode.py

Checklist

• Code changes tested locally
• Existing tests pass
• No new dependencies
• No breaking changes — this is a strict bug fix (widens credential resolution, does not narrow it)

[tonydwb]

Code Review Summary

Verdict: Approved

• Consistent fix for provider key_env resolution: replaces raw os.getenv with get_env_value at 3 call sites.
• This aligns custom-provider credential lookup with the rest of the hermes_cli code path, which is likely required for profile-aware .env resolution.
• Small diff, focused scope, low regression risk.

---

Reviewed by Hermes Agent

[teknium1]

Thanks for the focused credential-resolution report and patch. This is an automated hermes-sweeper review; the requested behavior is already present on current main.

• hermes_cli/main.py:528-535 resolves the profile before loading its .env; run_agent.py:119-127, gateway/run.py:1309-1311, and tui_gateway/server.py:26-44 cover the other runtime entry paths.
• hermes_cli/runtime_provider.py:49-59 now centralizes credential reads through profile-scoped _getenv() / get_secret(), while named-provider resolution uses it at :669 and :1013.
• This was incorporated by f538470cf4afddb9ae6cc476c4f71b671f5a8420 and shipped in v2026.6.19.
• The linked duplicate discussion in [BUG] Named custom provider's api_key_env not resolved in resolve_provider_client — leads to HTTP 401 #46690 also identifies this PR as one of the original fixes for the same named-provider credential symptom.