Problem

hermes_cli/doctor.py uses os.getenv() to read API keys and base URL env vars, which only reads from os.environ. Values stored in ~/.hermes/.env (the standard location for API keys) are silently missed.

This causes:

• API key blindspot: doctor reports keys as "not configured" when they exist only in ~/.hermes/.env
• Base URL fallback: providers with custom BASE_URL in .env (like DASHSCOPE_BASE_URL) fall back to wrong registry defaults, causing false "invalid key" reports

Same pattern as #18757 (fixed in auth.py) — os.getenv() vs get_env_value() inconsistency.

Fix

Replace os.getenv() with get_env_value() (with os.getenv() fallback) at 3 call sites:

1. Line 998: openrouter_key = os.getenv("OPENROUTER_API_KEY") → _get_env_value("OPENROUTER_API_KEY") or os.getenv("OPENROUTER_API_KEY")
2. Line 1111: _key = os.getenv(_ev, "") in provider loop → _get_env_value(_ev) or os.getenv(_ev, "")
3. Line 1123: _base = os.getenv(_base_env, "") for base URL → _get_env_value(_base_env) or os.getenv(_base_env, "")

The fallback to os.getenv() ensures values injected directly into the process environment (e.g., Docker, CI) still work.

Related

• [Bug]: resolve_api_key_provider_credentials() uses os.getenv for base_url_env_var — misses ~/.hermes/.env values #18757 — same fix applied to auth.py
• Skill docs note this as a known standing issue: doctor.py line 1122 (_base = os.getenv(_base_env, "")) still uses os.getenv