Bug Description

resolve_api_key_provider_credentials() in hermes_cli/auth.py resolves base_url_env_var using os.getenv(), which does not read from ~/.hermes/.env. Providers with a custom base URL stored only in .env (not exported in the shell) get the wrong endpoint — the default inference_base_url from PROVIDER_REGISTRY.

The same function correctly uses get_env_value() for API key resolution, creating an inconsistency: API keys are found, but base URLs are not.

The identical pattern also exists in hermes_cli/runtime_provider.py.

Steps to Reproduce

1. Configure a provider with a custom base URL (e.g., Xiaomi with token-plan-cn.xiaomimimo.com instead of the default api.xiaomimimo.com)
2. Set the base URL in ~/.hermes/.env only — do not export it in the shell:

   XIAOMI_BASE_URL=https://token-plan-cn.xiaomimimo.com/v1
   

3. Set the same provider as an auxiliary task provider in config.yaml:

   auxiliary:
     title_generation:
       provider: xiaomi
       model: mimo-v2.5
       base_url: ''

4. Start a new conversation via gateway (Telegram/Discord/CLI)
5. Observe that the auxiliary task (e.g., auto-title) fails with 401

Expected Behavior

The auxiliary client should resolve XIAOMI_BASE_URL from ~/.hermes/.env via get_env_value() and use https://token-plan-cn.xiaomimimo.com/v1 — the same way it resolves XIAOMI_API_KEY.

Actual Behavior

The auxiliary client uses os.getenv("XIAOMI_BASE_URL") which returns None (env var not in os.environ), then falls back to pconfig.inference_base_url (https://api.xiaomimimo.com/v1). The request hits the wrong endpoint and returns 401.

Affected Component

• Configuration (config.yaml, .env, hermes setup)
• Agent Core (conversation loop, context compression, memory)

Debug Report

N/A — this is a code-level bug identifiable from source. No environment-specific info needed.

Operating System

Ubuntu 24.04 (ARM64)

Python Version

3.12

Hermes Version

v0.12.0 (2026.4.30) — persists on origin/main (98c98821f)

Additional Logs / Traceback

Title generation failed: Error code: 401 - {'error': {'message': 'Invalid API Key', 'param': 'Please provide valid API Key', 'code': '401', 'type': 'invalid_key'}}

Root Cause Analysis

hermes_cli/auth.py L3529-3531 — resolve_api_key_provider_credentials():

# API key — uses get_env_value() ✅ (reads .env file)
for env_var in pconfig.api_key_env_vars:
    val = (get_env_value(env_var) or "").strip()

# base_url — uses os.getenv() ❌ (does NOT read .env file)
env_url = ""
if pconfig.base_url_env_var:
    env_url = os.getenv(pconfig.base_url_env_var, "").strip()

hermes_cli/runtime_provider.py — same pattern:

env_url = ""
if pconfig.base_url_env_var:
    env_url = os.getenv(pconfig.base_url_env_var, "").strip().rstrip("/")

Proposed Fix

Replace os.getenv with get_env_value in both locations:

# auth.py — resolve_api_key_provider_credentials()
env_url = ""
if pconfig.base_url_env_var:
    env_url = (get_env_value(pconfig.base_url_env_var) or "").strip()

# runtime_provider.py — same change
env_url = ""
if pconfig.base_url_env_var:
    env_url = (get_env_value(pconfig.base_url_env_var) or "").strip().rstrip("/")

Same Bug Class as #15914 and #17140

This is the same os.getenv() vs get_env_value() pattern fixed in:

• PR fix(auth): resolve API keys from ~/.hermes/.env and credential_pool #16101 (closed [Bug]: Fallback chain collapses when API key unavailable in os.environ but present in credential_pool #15914) — API key + credential_pool
• PR fix(voice): resolve API keys from ~/.hermes/.env in TTS + STT tools (#17140) #17434 (closed [Bug]: TTS tools fail to read API keys from ~/.hermes/.env — os.getenv() doesn't see dotenv values #17140) — TTS/STT tools

The base_url_env_var resolution was missed in both fixes.

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR