hermes - ✅(Solved) Fix fix(model): avoid persisting key_env-resolved secrets [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#15803Fetched 2026-04-26 05:24:55
View on GitHub
Comments
0
Participants
1
Timeline
6
Reactions
0
Author
Participants
Timeline (top)
labeled ×4cross-referenced ×1renamed ×1

Root Cause

  • key_env is the recommended way to avoid plaintext API keys in config.
  • Model selection should not silently downgrade credential hygiene.
  • Runtime provider resolution and auxiliary model calls already rely on env-based credentials.

Fix Action

Fixed

PR fix notes

PR #15805: fix(model): avoid persisting key_env-resolved secrets

Description (problem / solution / changelog)

Summary

Fixes #15803.

Simplifies _model_flow_named_custom() credential handling for /models discovery:

  1. If key_env is set, resolve it and use that value for the /models request.
  2. If key_env is missing, fall back to inline api_key.
  3. When saving config, write only provider_info["api_key"]; never write the value resolved from key_env.

Why

Named providers in the new keyed providers: schema can be configured securely with:

providers:
  local-custom:
    base_url: http://localhost:8000/v1
    key_env: LOCAL_CUSTOM_KEY

Selecting a model should not copy LOCAL_CUSTOM_KEY's runtime value into providers.<name>.api_key.

Tests

  • python -m pytest tests/hermes_cli/test_terminal_menu_fallbacks.py::test_named_provider_model_picker_uses_key_env_without_persisting_secret tests/hermes_cli/test_terminal_menu_fallbacks.py::test_named_custom_provider_model_picker_falls_back_on_terminalmenu_runtime_error -q
  • python -m pytest tests/hermes_cli/test_terminal_menu_fallbacks.py -q

Changed files

  • hermes_cli/main.py (modified, +9/-12)
  • tests/hermes_cli/test_terminal_menu_fallbacks.py (modified, +59/-0)

Code Example

providers:
  crs-henkee:
    name: CRS Henkee
    base_url: http://127.0.0.1:3000/api/v1
    key_env: HERMES_CRS_HENKEE_KEY
    transport: anthropic_messages
    model: claude-opus-4-7
    default_model: claude-opus-4-7

custom_providers: []
RAW_BUFFERClick to expand / collapse

Bug Description

hermes model resolves a named provider's key_env for /models discovery, but the model picker should treat that key as request-only and must not persist the resolved secret back into config.yaml.

The intended credential behavior is simple:

  1. If key_env is configured, resolve it and use that environment value for the /models request.
  2. If key_env is not configured, use inline api_key for the /models request.
  3. When saving config, write only the original inline provider_info["api_key"]; never write the value resolved from key_env.

Minimal Config

providers:
  crs-henkee:
    name: CRS Henkee
    base_url: http://127.0.0.1:3000/api/v1
    key_env: HERMES_CRS_HENKEE_KEY
    transport: anthropic_messages
    model: claude-opus-4-7
    default_model: claude-opus-4-7

custom_providers: []

Expected Behavior

The picker should use HERMES_CRS_HENKEE_KEY for the live /models request, then only persist the selected model/default_model. The actual cr_... secret should remain environment-only.

Why This Matters

  • key_env is the recommended way to avoid plaintext API keys in config.
  • Model selection should not silently downgrade credential hygiene.
  • Runtime provider resolution and auxiliary model calls already rely on env-based credentials.

extent analysis

TL;DR

Modify the model picker to treat the key_env as request-only and not persist the resolved secret back into config.yaml.

Guidance

  • Verify that the key_env is correctly resolved and used for the /models request by checking the request headers or payload.
  • Update the model picker to only write the original inline provider_info["api_key"] to config.yaml, without including the resolved key_env value.
  • Review the credential handling logic to ensure it follows the intended behavior: using key_env if configured, and inline api_key otherwise.
  • Test the model picker with both configured and unconfigured key_env scenarios to ensure correct behavior.

Example

# Before saving config
provider_info = {
    "api_key": "inline_api_key",
    "key_env": "HERMES_CRS_HENKEE_KEY"
}

# After saving config
provider_info = {
    "api_key": "inline_api_key"
}

Notes

The fix relies on correctly distinguishing between the key_env resolution for requests and the persistence of credentials in config.yaml. Ensure that the updated logic does not introduce any security vulnerabilities.

Recommendation

Apply workaround: Modify the model picker to treat key_env as request-only, as this approach maintains credential hygiene and aligns with the recommended configuration practice.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING