Skip to content

fix(cli,auth): resolve base_url_env_var from ~/.hermes/.env#20656

Open
haosenwang1018 wants to merge 1 commit into
NousResearch:mainfrom
haosenwang1018:fix/18757-base-url-dotenv-resolution
Open

fix(cli,auth): resolve base_url_env_var from ~/.hermes/.env#20656
haosenwang1018 wants to merge 1 commit into
NousResearch:mainfrom
haosenwang1018:fix/18757-base-url-dotenv-resolution

Conversation

@haosenwang1018

Copy link
Copy Markdown

Issue

Closes #18757

Root cause

Provider base URLs declared via base_url_env_var (e.g. XIAOMI_BASE_URL, ARCEE_BASE_URL) resolved only through os.getenv — they didn't see ~/.hermes/.env. API keys already used get_env_value (which reads .env), so the function had two halves with inconsistent semantics: API key found, base URL silently fell back to the registry default.

The original report describes Xiaomi's token-plan-cn-cn.xiaomimimo.com endpoint silently regressing to the public api.xiaomimimo.com default → 401s on auxiliary tasks. The same inconsistency affected every API-key provider with a base_url_env_var (Arcee, GLM, Kimi, GMI, MiniMax, Stepfun, GMI, AI Gateway, OpenCode, Kilocode, HF, TokenHub, Ollama, Bedrock, Azure Foundry, etc.).

Fix

Four call sites needed the same .env-aware lookup. The bug report named the first one; the rest were grep'd from the same access pattern:

File Function Used by
hermes_cli/auth.py resolve_api_key_provider_credentials runtime auxiliary client (the original bug)
hermes_cli/auth.py get_api_key_provider_status hermes doctor status output
hermes_cli/auth.py resolve_external_process_provider_credentials Copilot ACP runtime
hermes_cli/runtime_provider.py _build_runtime_for_api_key_provider (around the existing pconfig.base_url_env_var block) main agent runtime selection

All four now use the same fallback pattern that API-key resolution already uses elsewhere in the file:

get_env_value(pconfig.base_url_env_var) or os.getenv(pconfig.base_url_env_var, "")

Behavior when the value is set in the shell environment is unchanged.

Tests

tests/hermes_cli/test_provider_base_url_dotenv.py (new) covers:

  • A .env-only base URL is now picked up by resolve_api_key_provider_credentials
  • The same value is reflected by get_api_key_provider_status (so hermes doctor no longer lies when a .env base URL is set)
  • The shell-env path still works (regression guard for the other direction)

Existing test_arcee_provider.py and test_runtime_provider_resolution.py also pass unchanged (139 tests in this scope, all green).

Closes NousResearch#18757

Provider base URLs declared via ``base_url_env_var`` were resolved
through ``os.getenv`` only — bypassing ``~/.hermes/.env``. API keys
already used ``get_env_value`` (which reads ``.env``), so users with
a base URL set only in ``.env`` (not exported in the shell) ended up
with a working API key but the registry default base URL.

The original report describes Xiaomi's ``token-plan-cn`` endpoint
silently regressing to the public ``api.xiaomimimo.com`` default,
producing 401s on auxiliary tasks. The same inconsistency affects
every API-key provider with a ``base_url_env_var``.

Four call sites were inconsistent and now use the
``get_env_value(...) or os.getenv(...)`` fallback (matching the
existing API-key resolution pattern):

- ``auth.get_api_key_provider_status`` (status / ``hermes doctor``)
- ``auth.resolve_api_key_provider_credentials`` (the original report)
- ``auth.resolve_external_process_provider_credentials`` (Copilot ACP)
- ``runtime_provider._build_runtime_for_api_key_provider``
  (auxiliary client base URL plumbing)

Tests cover the regression (``.env``-only base URL is now picked up)
and pin the existing shell-env behavior so we don't regress in the
other direction.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@alt-glitch alt-glitch added type/bug Something isn't working P2 Medium — degraded but workaround exists comp/cli CLI entry point, hermes_cli/, setup wizard area/auth Authentication, OAuth, credential pools labels May 6, 2026
@alt-glitch

Copy link
Copy Markdown
Collaborator

Duplicate of #18948 — both fix base_url_env_var resolution to use get_env_value() instead of bare os.getenv(). Please coordinate with that PR or close one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/auth Authentication, OAuth, credential pools comp/cli CLI entry point, hermes_cli/, setup wizard P2 Medium — degraded but workaround exists type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: resolve_api_key_provider_credentials() uses os.getenv for base_url_env_var — misses ~/.hermes/.env values

2 participants