Bug Description

hermes doctor has a false-negative bug for the kimi-coding-cn provider.

When Hermes is configured with KIMI_CN_API_KEY, hermes doctor does not recognize the key as a configured provider credential, and the Kimi / Moonshot (China) API probe can crash with:

str expected, not NoneType

This makes doctor report that API keys still need to be configured, even though the provider is already configured correctly.

I searched existing issues before filing this. I found similar hermes doctor false-negative issues such as #7074, #9516, #961, and the historical MiniMax doctor issue #811, but I did not find an issue specifically for KIMI_CN_API_KEY / kimi-coding-cn.

I also confirmed this on the latest upstream main as of April 14, 2026, on commit 16f9d0208429a16db983634dd11f62852faf329a.

Steps to Reproduce

1. Update to the latest upstream main.

2. Create an isolated Hermes home with only a China-region Kimi key in .env:

   tmp=$(mktemp -d)
   mkdir -p "$tmp"/{cron,sessions,logs,memories,skills}
   cp cli-config.yaml.example "$tmp/config.yaml"
   printf 'KIMI_CN_API_KEY=sk-test\n' > "$tmp/.env"

3. Run hermes doctor against that isolated Hermes home:

   HERMES_HOME="$tmp" hermes doctor

4. Observe that doctor does not recognize KIMI_CN_API_KEY as a configured provider key, and the Kimi / Moonshot (China) API probe reports a Python exception instead of a normal API result.

Expected Behavior

hermes doctor should treat KIMI_CN_API_KEY as a configured provider credential.

For kimi-coding-cn, the doctor check should probe the China endpoint normally and report a normal result such as:

• configured / key detected
• invalid API key
• HTTP status from the actual provider

It should not tell the user to run hermes setup for API keys when KIMI_CN_API_KEY is already configured, and it should not crash with str expected, not NoneType.

Actual Behavior

With only KIMI_CN_API_KEY present in .env, hermes doctor reports a false negative similar to:

Found 2 issue(s) to address:

1. Run 'hermes setup' to configure API keys
2. Run 'hermes setup' to configure missing API keys for full tool access

In an isolated repro, the relevant doctor output shows:

• .env exists
• No API key found in .../.env
• Checking Kimi / Moonshot (China) API... (str expected, not NoneType)

I also verified separately that the actual runtime path can work with a real China-region Kimi key, so this is a hermes doctor diagnostic bug rather than a provider configuration bug.

Affected Component

Configuration (config.yaml, .env, hermes setup)

Messaging Platform (if gateway-related)

No response

Debug Report

Report     https://paste.rs/OKSKA
  agent.log  https://paste.rs/9FUED

Operating System

macOS 26.1

Python Version

3.11.15

Hermes Version

Hermes Agent v0.9.0 (2026.4.13)

Additional Logs / Traceback (optional)

Minimal repro output:


No API key found in .../.env
Checking Kimi / Moonshot (China) API... (str expected, not NoneType)


With a real configured China-region Kimi key, runtime usage succeeds, but `hermes doctor` still incorrectly suggests running `hermes setup` to configure API keys.

Root Cause Analysis (optional)

On current main, this appears to have two separate bugs in hermes_cli/doctor.py:

1. _PROVIDER_ENV_HINTS includes KIMI_API_KEY but does not include KIMI_CN_API_KEY, so _has_provider_env_config() returns False for China-only Kimi setups.

2. In the provider connectivity loop, the kimi-coding-cn entry uses base_env=None, but the code later calls os.getenv(_base_env, "") unconditionally. That causes:

   TypeError: str expected, not NoneType

As of April 14, 2026, this is in hermes_cli/doctor.py around:

• _PROVIDER_ENV_HINTS near the top of the file
• the Kimi China provider entry in the API connectivity table
• the later os.getenv(_base_env, "") call in the doctor probe loop

Proposed Fix (optional)

Small, focused fix:

1. Add KIMI_CN_API_KEY to _PROVIDER_ENV_HINTS.
2. Make the base-URL override lookup null-safe:
   • treat base_env=None as “no override env var”
   • only call os.getenv() when a base env var name exists
3. Keep the Kimi China probe target on https://api.moonshot.cn/v1/models.
4. Do not change runtime provider resolution or model selection behavior.

I already reproduced this locally and validated that a narrow fix corrects the doctor output without changing runtime chat behavior.

Are you willing to submit a PR for this?

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