After completing the onboarding wizard with the LM Studio provider, users
saw LM Studio in the model picker and could chat normally, but Settings →
Providers showed no LM Studio entry — or rendered it with has_key=False
and configurable=False even when LMSTUDIO_API_KEY was already in
~/.hermes/.env. There was no UI surface to add or update the key.
Root cause:
api/providers.py:_PROVIDER_ENV_VAR — the dict that maps each provider id
to its env-var name — is missing an "lmstudio: LMSTUDIO_API_KEY" entry.
That dict drives two things:
1. _provider_has_key(pid) — env-var-based key detection. Returns False
and sets key_source='none' if the pid isn't in the dict, regardless
of what's in .env or os.environ.
2. get_providers() line 364:
"configurable": not is_oauth and pid in _PROVIDER_ENV_VAR,
Without the entry, configurable=False, hiding the "Add API key"
form in the UI.
So with no map entry, an LM Studio user with a working LMSTUDIO_API_KEY
gets has_key=False (wrong) AND no UI to fix it (wrong-er).
Same bug shape as #1410 (Ollama Cloud / local Ollama env-var collision).
The #1410 fix dropped bare "ollama" from _PROVIDER_ENV_VAR because
OLLAMA_API_KEY was shared with ollama-cloud and the runtime semantics
made the local key detection ambiguous. LMSTUDIO_API_KEY has no such
collision — it's only consumed by the lmstudio runtime.
Verified via reproduction:
before fix: lmstudio.has_key=False, configurable=False, key_source='none'
after fix: lmstudio.has_key=True, configurable=True, key_source='env_file'
5 regression tests in tests/test_issue1420_lmstudio_provider_env_var.py:
1. _PROVIDER_ENV_VAR['lmstudio'] == 'LMSTUDIO_API_KEY'
2. LMSTUDIO_API_KEY in env → has_key=True + configurable=True
3. providers.lmstudio.api_key in config.yaml → has_key=True (fallback path)
4. No env, no config → has_key=False but configurable=True (UI fix surface)
5. LMSTUDIO_API_KEY doesn't cross-detect any other provider
Mutation-verified: reverting the map entry causes 4 of 5 tests to fail
with clear assertion messages naming the bug (the 5th — config.yaml
fallback — is independent of the env-var path and intentionally remains
green to pin that the existing path keeps working).
Scope discipline:
#1420's broader thread surfaces a sibling bug — the onboarding wizard
never probes the configured <base_url>/v1/models endpoint before
persisting (the wizard accepts unreachable URLs silently with no
model-list dropdown population). That bug is being filed separately
and is NOT addressed here. Adding a probe touches the wizard UX flow,
has timeout / error-handling implications, and warrants its own design
pass.
Closes#1420 (the "LM Studio missing from Settings" half — feature-
request half about provider catalog support is already shipped: LM
Studio has been a first-class provider in api/onboarding.py since long
before this issue).
Co-authored-by: chwps <106549456+chwps@users.noreply.github.com>
Co-authored-by: AdoneyGalvan <25235323+AdoneyGalvan@users.noreply.github.com>
d3c7ac182b