Bug Description

I ran into a misleading 'hermes doctor' case with OAuth-backed providers.

In my setup, Hermes was using Nous Portal, and Google Gemini OAuth was already logged in and healthy. But hermes doctor still surfaced 'Check GOOGLE_API_KEY in .env' in the final summary because the direct Gemini API key probe failed.

The same logic also applies to provider families like MiniMax, where a healthy OAuth path can coexist with a bad direct API key.

That feels wrong because the API Connectivity section can still show the bad key, but the final summary should be reserved for blocking issues. If the OAuth path for that provider family is already healthy, the direct-key failure is no longer a blocking setup problem.

Expected behavior:

• keep the 'invalid API key' line in API Connectivity
• do not promote it into the final blocking summary when a healthy OAuth fallback already exists

Steps to Reproduce

1. Log into Google Gemini OAuth so the OAuth path is healthy.
2. Leave an invalid GOOGLE_API_KEY configured in ~/.hermes/.env.
3. Run hermes doctor.
4. Check the API Connectivity section.
5. Check the final issues summary.
6. Notice that doctor still reports Check GOOGLE_API_KEY in .env as a blocking summary issue even though the Gemini OAuth path is already healthy.

Expected Behavior

The API Connectivity section can still report that the direct API key is invalid.

But if the matching OAuth path is already healthy, that direct-key problem should not be promoted into the final blocking summary.

Actual Behavior

hermes doctor still promotes the bad direct API key into the final summary, even when the matching OAuth path is already healthy.

In my repro, Hermes was using a healthy OAuth-backed setup, but doctor still ended with:

Check GOOGLE_API_KEY in .env

That makes the setup look more broken than it really is.

Affected Component

CLI (interactive chat)

Messaging Platform (if gateway-related)

No response

Debug Report

Report     https://paste.rs/Sw0iF
agent.log  https://paste.rs/0FCf8

Operating System

Ubuntu on WSL2 (Windows 11)

Python Version

Python 3.12.3

Hermes Version

Hermes Agent v0.13.0 (2026.5.7)

Additional Logs / Traceback (optional)

A representative real-world symptom was:

- healthy 'Google Gemini OAuth' shown in the Auth Providers section
- but 'Check GOOGLE_API_KEY in .env' still appeared in the final summary

The API Connectivity section can correctly show an invalid direct key, but the final blocking summary should not treat it as a setup blocker when the OAuth path is already healthy.

Root Cause Analysis (optional)

I traced this to the API Connectivity summary handling in hermes_cli/doctor.py.

Each connectivity probe returns both display lines and summary issues. Later in run_doctor, those issues are appended directly into the final summary.

That means a failed direct API-key probe can become a final blocking issue even when the same provider family already has a healthy OAuth runtime path.

I prepared a fix that keeps the failed connectivity row visible, but suppresses the final summary issue when a healthy OAuth fallback already exists for the same provider family.

Relevant file:

• hermes_cli/doctor.py

Proposed Fix (optional)

Keep the failed API Connectivity row visible, but do not promote the direct-key issue into the final blocking summary when the same provider family already has a healthy OAuth fallback.
I also added focused regression coverage for:

• Gemini OAuth + invalid direct Gemini key
• MiniMax OAuth + invalid direct MiniMax key

Are you willing to submit a PR for this?

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