fix(model): avoid persisting key_env-resolved secrets to providers entry#16372
Merged
Conversation
When 'hermes model' runs against a providers: (keyed-schema) entry that
relies only on key_env, the picker resolves the env var for the live
/models request and then wrote a synthesized 'api_key: ${KEY_ENV}' back
to the providers.<key> entry. That's redundant — the runtime already
resolves from key_env directly — and it clutters configs that
intentionally keep credentials out of config.yaml.
Only persist provider_entry['api_key'] when the user originally had an
inline value (literal secret or ${VAR} template). Entries that declared
only key_env stay clean on save.
Fixes #15803.
negaterium
pushed a commit
to negaterium/hermes-agent
that referenced
this pull request
Apr 27, 2026
…try (NousResearch#16372) When 'hermes model' runs against a providers: (keyed-schema) entry that relies only on key_env, the picker resolves the env var for the live /models request and then wrote a synthesized 'api_key: ${KEY_ENV}' back to the providers.<key> entry. That's redundant — the runtime already resolves from key_env directly — and it clutters configs that intentionally keep credentials out of config.yaml. Only persist provider_entry['api_key'] when the user originally had an inline value (literal secret or ${VAR} template). Entries that declared only key_env stay clean on save. Fixes NousResearch#15803. (cherry picked from commit 8258f4d)
2 tasks
cluricaun28
referenced
this pull request
in cluricaun28/Logos
Apr 28, 2026
…try (#16372)
When 'hermes model' runs against a providers: (keyed-schema) entry that
relies only on key_env, the picker resolves the env var for the live
/models request and then wrote a synthesized 'api_key: ${KEY_ENV}' back
to the providers.<key> entry. That's redundant — the runtime already
resolves from key_env directly — and it clutters configs that
intentionally keep credentials out of config.yaml.
Only persist provider_entry['api_key'] when the user originally had an
inline value (literal secret or ${VAR} template). Entries that declared
only key_env stay clean on save.
Fixes #15803.
ulasbilgen
pushed a commit
to ulasbilgen/hermes-adhd-agent
that referenced
this pull request
May 1, 2026
…try (NousResearch#16372) When 'hermes model' runs against a providers: (keyed-schema) entry that relies only on key_env, the picker resolves the env var for the live /models request and then wrote a synthesized 'api_key: ${KEY_ENV}' back to the providers.<key> entry. That's redundant — the runtime already resolves from key_env directly — and it clutters configs that intentionally keep credentials out of config.yaml. Only persist provider_entry['api_key'] when the user originally had an inline value (literal secret or ${VAR} template). Entries that declared only key_env stay clean on save. Fixes NousResearch#15803.
2 tasks
donald131
pushed a commit
to donald131/hermes-agent
that referenced
this pull request
May 2, 2026
…try (NousResearch#16372) When 'hermes model' runs against a providers: (keyed-schema) entry that relies only on key_env, the picker resolves the env var for the live /models request and then wrote a synthesized 'api_key: ${KEY_ENV}' back to the providers.<key> entry. That's redundant — the runtime already resolves from key_env directly — and it clutters configs that intentionally keep credentials out of config.yaml. Only persist provider_entry['api_key'] when the user originally had an inline value (literal secret or ${VAR} template). Entries that declared only key_env stay clean on save. Fixes NousResearch#15803.
02356abc
pushed a commit
to 02356abc/hermes-agent
that referenced
this pull request
May 14, 2026
…try (NousResearch#16372) When 'hermes model' runs against a providers: (keyed-schema) entry that relies only on key_env, the picker resolves the env var for the live /models request and then wrote a synthesized 'api_key: ${KEY_ENV}' back to the providers.<key> entry. That's redundant — the runtime already resolves from key_env directly — and it clutters configs that intentionally keep credentials out of config.yaml. Only persist provider_entry['api_key'] when the user originally had an inline value (literal secret or ${VAR} template). Entries that declared only key_env stay clean on save. Fixes NousResearch#15803.
dannyJ848
pushed a commit
to dannyJ848/hermes-agent
that referenced
this pull request
May 17, 2026
…try (NousResearch#16372) When 'hermes model' runs against a providers: (keyed-schema) entry that relies only on key_env, the picker resolves the env var for the live /models request and then wrote a synthesized 'api_key: ${KEY_ENV}' back to the providers.<key> entry. That's redundant — the runtime already resolves from key_env directly — and it clutters configs that intentionally keep credentials out of config.yaml. Only persist provider_entry['api_key'] when the user originally had an inline value (literal secret or ${VAR} template). Entries that declared only key_env stay clean on save. Fixes NousResearch#15803.
gweeteve
pushed a commit
to gweeteve/hermes-agent
that referenced
this pull request
Jun 2, 2026
…try (NousResearch#16372) When 'hermes model' runs against a providers: (keyed-schema) entry that relies only on key_env, the picker resolves the env var for the live /models request and then wrote a synthesized 'api_key: ${KEY_ENV}' back to the providers.<key> entry. That's redundant — the runtime already resolves from key_env directly — and it clutters configs that intentionally keep credentials out of config.yaml. Only persist provider_entry['api_key'] when the user originally had an inline value (literal secret or ${VAR} template). Entries that declared only key_env stay clean on save. Fixes NousResearch#15803.
Egavasyug
pushed a commit
to Egavasyug/hermes-agent
that referenced
this pull request
Jun 10, 2026
…try (NousResearch#16372) When 'hermes model' runs against a providers: (keyed-schema) entry that relies only on key_env, the picker resolves the env var for the live /models request and then wrote a synthesized 'api_key: ${KEY_ENV}' back to the providers.<key> entry. That's redundant — the runtime already resolves from key_env directly — and it clutters configs that intentionally keep credentials out of config.yaml. Only persist provider_entry['api_key'] when the user originally had an inline value (literal secret or ${VAR} template). Entries that declared only key_env stay clean on save. Fixes NousResearch#15803.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #15803.
Summary
hermes modelno longer writes a synthesizedapi_key: ${KEY_ENV}to aproviders:entry that only declaredkey_env.Root cause:
_model_flow_named_custom'sproviders:persistence branch always called_custom_provider_api_key_config_value(), which falls back to${KEY_ENV}when no inline api_key exists. For the keyed schema that fallback is redundant — the runtime already resolves credentials fromkey_envdirectly — and it clutters configs that intentionally keep secrets out ofconfig.yaml.Changes
hermes_cli/main.py: gate theprovider_entry["api_key"]write on whetherprovider_infooriginally carried an inline api_key (literal or${VAR}template). Entries with onlykey_envstay clean.tests/hermes_cli/test_custom_provider_model_switch.py: two regression tests — (a) key_env-only entry gets noapi_keyfield after the picker, and no plaintext secret appears on disk; (b) an existing inline${VAR}template is preserved across the picker.Validation
E2E reproduced the reporter's exact config against unpatched main (writes
api_key: ${HERMES_CRS_HENKEE_KEY}), then against the fix (entry unchanged apart fromdefault_modelupdate). 162 tests across 6 relevant files pass:Legacy
custom_providersbehavior (writing${VAR}when only key_env is set) is unchanged — still covered by the existingtest_key_env_custom_provider_persists_reference_not_secrettest.