`hermes doctor` reports stale `ui-tui` npm vulnerability and false-positive `gemini (invalid API key)`

[mbobele]

Bug report: hermes doctor reports stale ui-tui npm vulnerability and false-positive gemini (invalid API key)

Environment

• OS: macOS
• Hermes home: /Users/bobele/.hermes
• Node: /Users/bobele/.hermes/node/bin/node (v22.22.3)
• npm: /Users/bobele/.hermes/node/bin/npm (v10.9.8)
• Hermes: 0.16.0

Description

hermes doctor continues reporting two issues even though the underlying conditions are fixed or working:

1. ui-tui workspace has 1 npm vulnerability
2. gemini (invalid API key)

Observed behavior

hermes doctor outputs:

  Found 3 issue(s) to address:

  1. ui-tui workspace has 1 npm vulnerability
  2. Check GOOGLE_API_KEY in .env
  3. Run 'hermes setup' to configure missing API keys for full tool access

  ✗ gemini (invalid API key)

Actual state when this was reproduced

• ~/.hermes/.env contains valid GOOGLE_API_KEY and GEMINI_API_KEY
• hermes chat -q "reply ok" -m gemini-3.1-flash-lite returns ok
• /Users/bobele/.hermes/node/bin/npm --prefix /Users/bobele/.hermes/hermes-agent audit --omit=dev --json returns 0 vulnerabilities
• hermes doctor --fix does not change the reported issues

Steps to reproduce

1. Configure Google Gemini in Hermes setup or .env
2. Run hermes chat -q "reply ok" -m gemini-3.1-flash-lite
3. Run hermes doctor
4. Observe stale ui-tui npm warning despite clean npm audit
5. Observe false-positive gemini (invalid API key) despite successful chat response

Expected behavior

• hermes doctor should reflect current npm audit results for ui-tui / hermes-agent
• hermes doctor should not report invalid API key when Gemini calls succeed
• Repetitive guidance like Run 'hermes setup' to configure missing API keys for full tool access should not remain after setup/auth is saved

Suggested fix

• Recompute npm workspace checks against the detected/active Node/npm
• Align the Gemini connectivity probe with the runtime provider/model path
• Clear false-positive auth warnings when a successful API call has already validated credentials

[carter-smalls]

With API key, the root cause is usually upstream — timeout guards and failover are the fix.

npx ai-doctor@latest --json

Flags missing retry configs and provider health issues so you can patch them now.

[Hicsy]

feels like 2x different issues

[garrigaandres35-code]

Reproducing on Windows with Hermes v0.19.0 (2026.7.20, commit 2078af6).

Environment:

• OS: Windows (pwsh 5.1)
• Python: 3.11.15
• Node: system Node
• Hermes home: C:\Users\aseso\AppData\Local\hermes
• Install method: git (managed)

hermes doctor output:

• web workspace: 7 high (build-tool advisory — brace-expansion/minimatch via eslint, react-router)
• ui-tui workspace: 8 high (build-tool advisory — same root causes)

Attempted fixes:
1.
pm audit fix — fails with peer dep conflicts (eslint-plugin-react expects eslint ^3-^7, workspace uses ^9)
2.
pm audit fix --force — downgrades react-router-dom from 8.x to 7.11.0, which introduces more CVEs (RCE, XSS, open redirect). Reverted.
3. hermes doctor --fix — no change

All vulnerabilities are build-time (eslint, react-router), not runtime. The lockfile bump to eslint 10+ and react-router 7.18+ requires upstream package.json changes to resolve peer dep constraints.

Separately, hermes doctor also reports ✗ Anthropic API (invalid API key) and ⚠ gemini (HTTP 400) — the Gemini false-positive matches the original report.

[GottZ]

This was generated by AI during triage.

Summary

One PR addresses issue #48689. #48752 directly suppresses dev-only npm audit noise with --omit=dev, but its Gemini/OAuth changes no longer match current main, where the Google API-key request header has already been corrected and Gemini is no longer treated as an OAuth provider.

Related pull requests

• fix: reduce stale doctor audit and oauth noise #48752 best fix — (+84/-6) — partial fix; revise before merge: the npm audit change addresses the reported stale ui-tui warning, while the Gemini branch calls a removed OAuth helper and changes direct-key failure visibility. Despite the keep_open review on fix: reduce stale doctor audit and oauth noise #48752, the diff supports retaining the focused --omit=dev fix, but the contributor review must be addressed by dropping the obsolete Gemini OAuth branch and preserving the existing diagnostic contract.

Suggested consolidation

Merge #48752 after revision — keep the tested npm audit --omit=dev change, drop the stale Gemini OAuth fallback, retain the current-main x-goog-api-key fix, and preserve direct API-key failure visibility while suppressing only redundant summary noise. There are no competing PRs to close as duplicates.

Complex graph

flowchart LR
    classDef open fill:#dbeafe,stroke:#1d4ed8,color:#1e3a8a
    classDef merged fill:#dcfce7,stroke:#15803d,color:#14532d
    classDef closed fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    classDef unverified fill:#f3f4f6,stroke:#9ca3af,color:#374151
    classDef best stroke-width:3px,stroke:#b45309
    classDef target stroke-width:3px,stroke:#4338ca
    I48689(["issue #48689 (open)"])
    P48752["PR #48752 (open)"]
    P48752 -->|best fix| I48689
    class I48689 open
    class I48689 target
    class P48752 open
    class P48752 best
    click I48689 "https://github.com/NousResearch/hermes-agent/issues/48689"
    click P48752 "https://github.com/NousResearch/hermes-agent/pull/48752"

Loading

Graph: solid arrow = fixes / best fix, dashed arrow = partial or unverified (see edge label); boxed group = PRs duplicating each other; amber border = best fix; indigo border = target; gray node = closed or no verify verdict yet (state tag in the node label).

Cross-PR triage: Reviewed 1 pull request and 1 issue in this complex. Each diff was read against this issue; Assessment working set: 6 kB of PR diffs, 6 kB of issue/PR text, 3 kB of discussion (5 comments), 2 verify verdicts. verdicts reflect diff content, not PR titles. Part of an automated triage batch.

[datanerdie]

On the npm-audit half of this issue — there's a detail in how doctor reports these that I think matters before #48752 lands, plus a small factual correction to the thread.

The "build-time tooling (not runtime)" line is unconditional

hermes_cli/doctor.py:1976 prints this for any workspace advisory, regardless of what the advisory actually is:

check_info(
    "  ^ build-time tooling (not runtime); if manual npm remediation "
    "errors with an arborist crash it's a known npm bug — clears "
    "via a lockfile bump"
)

It's a hardcoded string, not derived from the audit payload. Right now it's wrong on both claims for the web workspace:

"not runtime" — of web's 8 findings, 2 are react-router / react-router-dom (GHSA-qwww-vcr4-c8h2), which is a runtime dependency of the dashboard, not build tooling. The other 6 genuinely were build-time.

"clears via lockfile bump" — it doesn't. The brace-expansion chain needs an ESLint 9 → 10 manifest bump; ESLint 9 hard-depends on minimatch@3 → brace-expansion@^1.x, and no patched 1.x exists. Only postcss cleared via lockfile. Details and a working fix in #68736.

This is measurably misleading people rather than being a cosmetic nit — @garrigaandres35-code's comment above repeats it back verbatim ("All vulnerabilities are build-time (eslint, react-router), not runtime"), which is exactly the conclusion the hardcoded string invites.

Why this matters for #48752

#48752 switches doctor to npm audit --omit=dev. That would suppress react-router too, since the finding reaches web through a production dependency but the advisory noise is being filtered wholesale rather than by advisory content. Combined with the "not runtime" message, a genuine runtime advisory gets hidden on a false premise.

Suggestion: derive the message from the audit JSON — doctor already parses it, and vulnerabilities[*].nodes / the dev flag are enough to say "N build-time, M runtime" accurately — and scope any --omit=dev filtering to what's actually dev-only. Happy to file that as its own issue if it's cleaner to track separately from the Gemini half of this report.

Small correction

npm audit fix --force — downgrades react-router-dom from 8.x to 7.11.0

There's no 8.x of react-router-dom — I queried the registry directly: 1058 versions, majors 0/4/5/6/7 only, dist-tags.latest = 7.18.1. The 8.x line belongs to react-router, which is a separate package (react-router-dom@7.18.1 is a thin re-export shim whose only dependency is react-router@7.18.1).

So the --force path is 7.18.1 → 7.11.0, a seven-minor downgrade rather than a major one. I haven't verified the "introduces more CVEs (RCE, XSS, open redirect)" claim either way, but it's worth noting react-router-dom has no non-vulnerable release for GHSA-qwww-vcr4-c8h2 — 7.18.1 sits inside the affected 7.12.0 - 8.2.0 range, so there is nothing to upgrade to within that package.

For what it's worth the advisory is RSC-mode-only and the dashboard is a client-only SPA (<BrowserRouter>, no RSC entry point, no server router or actions), so it looks accept-and-document rather than remediate.

Environment for the above: Hermes v0.19.0 (2026.7.20), upstream d71033a4, Linux, Node v24.18.0, npm 11.16.0.

[GottZ]

This was generated by AI during triage.

Delta since our previous triage comment

@datanerdie extends our previous analysis by identifying an additional audit-reporting defect: the explanatory line labels every workspace advisory as build-time-only and lockfile-fixable, regardless of the audit payload. Their evidence indicates that this is inaccurate for runtime react-router findings and for the brace-expansion chain requiring an ESLint manifest upgrade, so #48752 does not fully correct the npm-audit diagnostics even though --omit=dev remains a useful focused change.

Changed pull requests

• fix: reduce stale doctor audit and oauth noise #48752 best fix — (+84/-6) — partial fix: The npm audit --omit=dev diff filters development-only advisories, but the new evidence shows it leaves the unconditional and potentially false “build-time tooling”/“clears via a lockfile bump” guidance unchanged. Consistent with the contributor keep_open review on fix: reduce stale doctor audit and oauth noise #48752, the PR still requires revision before merge, including the previously identified obsolete Gemini OAuth changes and this newly documented audit-message defect.

Suggested consolidation

Recommendation unchanged: merge #48752 only after the required revisions, now also correcting or qualifying the unconditional audit guidance; there are no duplicate PRs.

Complex graph unchanged since our previous triage comment.

Cross-PR triage: Reviewed 1 pull request and 1 issue in this complex. Each diff was read against this issue; Assessment working set: 6 kB of PR diffs, 6 kB of issue/PR text, 6 kB of discussion (6 comments), 2 verify verdicts. verdicts reflect diff content, not PR titles. Part of an automated triage batch.