Issue Station
Sign In
Tools hereToolbox

hermes - ✅(Solved) Fix [Bug]: setup wizard misclassifies many configured providers as first-time installs [1 pull requests]

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…

Fix Action

Fix / Workaround

Minimal Reproduction

source venv/bin/activate && python - <<'PY'
from hermes_cli import setup as s
from hermes_cli.config import save_env_value
from unittest.mock import patch
import tempfile, os

args = type('Args', (), {'section':None,'non_interactive':False,'reset':False})()
with patch.object(s, 'ensure_hermes_home'), \
     patch.object(s, 'is_interactive_stdin', return_value=True), \
     patch('hermes_cli.auth.get_active_provider', return_value=None), \
     patch.object(s, 'prompt_choice', side_effect=fake_prompt_choice), \
     patch.object(s, '_offer_openclaw_migration', return_value=False), \
     patch.object(s, '_run_first_time_quick_setup') as quick_setup, \
     patch.object(s, '_run_quick_setup') as existing_quick_setup:
    s.run_setup_wizard(args)
    print({'prompt': questions[0] if questions else None, 'first_time': quick_setup.called, 'existing': existing_quick_setup.called})
PY

PR fix notes

PR #13097: fix(cli): recognise every PROVIDER_REGISTRY provider in setup wizard (#13024)

Description (problem / solution / changelog)

Problem

run_setup_wizard only treated an install as "existing" when one of these was present:

  • OPENROUTER_API_KEY
  • OPENAI_BASE_URL
  • An OAuth provider from get_active_provider()

This excluded every API-key provider registered via PROVIDER_REGISTRY (Anthropic, Z.AI, MiniMax, Kimi, Copilot, …), even though hermes_cli.main._has_any_provider_configured() and the rest of the CLI already recognise them. Users with only ANTHROPIC_API_KEY (or similar) saw the first-time quick-setup flow on every invocation.

Fixes #13024.

Fix

Walk PROVIDER_REGISTRY and union the api_key_env_vars of every api_key-typed entry into the existence check, querying each via the same get_env_value helper the rest of setup uses. Keeps the lightweight env-vars-only approach of the previous check so existing tests that mock setup_mod.get_env_value continue to work.

Test plan

  • Added test_api_key_provider_install_detected_as_existing regression in tests/hermes_cli/test_setup_noninteractive.py.
  • pytest tests/hermes_cli/test_setup.py tests/hermes_cli/test_setup_openclaw_migration.py tests/hermes_cli/test_setup_noninteractive.py — 52 passed.
  • Reran the shell/Python repro from the issue against the fixed branch: install with only ANTHROPIC_API_KEY now hits the returning-user menu (_run_quick_setup branch), not the first-time flow.

Changed files

  • hermes_cli/setup.py (modified, +11/-4)
  • tests/hermes_cli/test_setup_noninteractive.py (modified, +33/-0)

Code Example

source venv/bin/activate && python - <<'PY'
from hermes_cli import setup as s
from hermes_cli.config import save_env_value
from unittest.mock import patch
import tempfile, os

tmp = tempfile.mkdtemp(prefix='hermes-existing-')
os.environ['HERMES_HOME'] = tmp
save_env_value('ANTHROPIC_API_KEY', 'sk-ant')

questions = []
def fake_prompt_choice(question, choices, default=0):
    questions.append(question)
    return 0

args = type('Args', (), {'section':None,'non_interactive':False,'reset':False})()
with patch.object(s, 'ensure_hermes_home'), \
     patch.object(s, 'is_interactive_stdin', return_value=True), \
     patch('hermes_cli.auth.get_active_provider', return_value=None), \
     patch.object(s, 'prompt_choice', side_effect=fake_prompt_choice), \
     patch.object(s, '_offer_openclaw_migration', return_value=False), \
     patch.object(s, '_run_first_time_quick_setup') as quick_setup, \
     patch.object(s, '_run_quick_setup') as existing_quick_setup:
    s.run_setup_wizard(args)
    print({'prompt': questions[0] if questions else None, 'first_time': quick_setup.called, 'existing': existing_quick_setup.called})
PY

---

{'prompt': 'How would you like to set up Hermes?', 'first_time': True, 'existing': False}
RAW_BUFFERClick to expand / collapse

Bug Description

run_setup_wizard() uses a much narrower "existing installation" check than the rest of the CLI, so installs configured with many supported providers are treated as first-time setups.

Affected code:

  • hermes_cli/setup.py:2754-2762
  • canonical provider detection for comparison: hermes_cli/main.py:194-225

Today the setup wizard only considers an install "existing" when at least one of these is present:

  • OPENROUTER_API_KEY
  • OPENAI_BASE_URL
  • OAuth provider from get_active_provider()

That excludes API-key providers such as Anthropic / Z.AI / MiniMax / Kimi etc., even though _has_any_provider_configured() already recognizes them through PROVIDER_REGISTRY.

Minimal Reproduction

source venv/bin/activate && python - <<'PY'
from hermes_cli import setup as s
from hermes_cli.config import save_env_value
from unittest.mock import patch
import tempfile, os

tmp = tempfile.mkdtemp(prefix='hermes-existing-')
os.environ['HERMES_HOME'] = tmp
save_env_value('ANTHROPIC_API_KEY', 'sk-ant')

questions = []
def fake_prompt_choice(question, choices, default=0):
    questions.append(question)
    return 0

args = type('Args', (), {'section':None,'non_interactive':False,'reset':False})()
with patch.object(s, 'ensure_hermes_home'), \
     patch.object(s, 'is_interactive_stdin', return_value=True), \
     patch('hermes_cli.auth.get_active_provider', return_value=None), \
     patch.object(s, 'prompt_choice', side_effect=fake_prompt_choice), \
     patch.object(s, '_offer_openclaw_migration', return_value=False), \
     patch.object(s, '_run_first_time_quick_setup') as quick_setup, \
     patch.object(s, '_run_quick_setup') as existing_quick_setup:
    s.run_setup_wizard(args)
    print({'prompt': questions[0] if questions else None, 'first_time': quick_setup.called, 'existing': existing_quick_setup.called})
PY

Observed:

{'prompt': 'How would you like to set up Hermes?', 'first_time': True, 'existing': False}

Expected Behavior

If Hermes already has a supported provider configured, the setup wizard should use the returning-user / existing-install flow consistently.

Actual Behavior

Installs with provider keys like ANTHROPIC_API_KEY are treated as brand-new installs.

Suggested Investigation Direction

Unify setup-wizard detection with the broader _has_any_provider_configured() logic (or share a common helper) so all supported providers are recognized consistently.

extent analysis

TL;DR

Update the run_setup_wizard() function to use the _has_any_provider_configured() logic for detecting existing installations.

Guidance

  • Review the hermes_cli/setup.py file, specifically lines 2754-2762, to understand the current implementation of the "existing installation" check.
  • Compare this with the canonical provider detection logic in hermes_cli/main.py lines 194-225 to identify the discrepancy.
  • Consider creating a common helper function that encapsulates the _has_any_provider_configured() logic to ensure consistency across the CLI.
  • Update the run_setup_wizard() function to use this new helper function for detecting existing installations.

Example

# Example of a potential common helper function
def has_existing_installation():
    return _has_any_provider_configured()

# Update run_setup_wizard() to use the new helper function
def run_setup_wizard():
    if has_existing_installation():
        # Existing installation flow
    else:
        # First-time setup flow

Notes

The provided reproduction script and expected behavior suggest that the issue is specific to the run_setup_wizard() function's detection logic. However, without further information about the _has_any_provider_configured() function, it's difficult to provide a complete solution.

Recommendation

Apply a workaround by updating the run_setup_wizard() function to use the _has_any_provider_configured() logic, as this is the most straightforward way to address the inconsistency in the setup wizard's detection logic.

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…
#api#installation#batch processing#GPU compatibility#latency issue

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

hermes - ✅(Solved) Fix [Bug]: setup wizard misclassifies many configured providers as first-time installs [1 pull requests]