[mujisashi]

Description

With a non-Ollama provider configured via environment variables, fo setup cannot succeed — and since every command outside _SETUP_GATE_ALLOWLIST is gated on setup_completed, the CLI is unusable for those users (fo analyze, fo organize, ...).

Reproduction (LM Studio, Ollama installed but not running):

FO_PROVIDER=openai \
FO_OPENAI_BASE_URL=http://<host>:1234/v1 \
FO_OPENAI_MODEL=qwen3-14b-mlx \
fo setup

⚠ Ollama is installed but not running
⚠ No models installed, will use: qwen2.5:7b-instruct-q4_K_M
 Framework     ollama
Configuration validation failed:
  ✗ Ollama framework selected but Ollama service is not running. Start it with: ollama serve

No existing issue.

Root cause

SetupWizard only knows about Ollama. detect_capabilities() probes Ollama alone, generate_config() always picks an Ollama model with framework="ollama", and validate_config() requires the Ollama service. It never consults config.provider_env, even though get_model_configs() gives FO_PROVIDER precedence over the saved profile at runtime — so the wizard validates a backend the CLI won't even use. Power-user mode only offers ollama / llama_cpp / mlx.

What changed

• src/file_organizer/core/backend_detector.py: new EndpointStatus + detect_openai_endpoint(base_url, api_key), which probes GET {base_url}/models (stdlib urllib, no new dependency; openai stays optional). Distinguishes missing API key (401/403 without key → "set FO_OPENAI_API_KEY"), rejected key, other HTTP errors, and unreachable hosts.
• src/file_organizer/core/setup_wizard.py:
  • SystemCapabilities gains provider, provider_text_model, provider_vision_model, endpoint_status.
  • detect_capabilities() reads the active provider via get_current_provider(); for non-Ollama providers it takes model names from get_model_configs_from_env(), and for openai probes the endpoint (falling back to OPENAI_API_KEY, matching the SDK).
  • generate_config() applies the env provider through a small _apply_env_provider() helper (kept separate to stay under the C901 limit).
  • validate_config() only applies Ollama checks when framework == "ollama" (the "model not installed" check previously ran whenever Ollama happened to be running, regardless of framework), and for openai fails on an unreachable endpoint or a model the endpoint doesn't serve, listing the available ones.
  • run() only emits Ollama next-step warnings for the Ollama provider.
• src/file_organizer/cli/setup.py: shows the active provider/model and endpoint status instead of Ollama status and install hints; quick-start uses the env model; power-user mode offers the endpoint's model list instead of the framework/Ollama-model prompts.
• Tests: TestDetectOpenAIEndpoint (real local HTTP server: valid key, missing key, wrong key, unreachable host) and TestEnvProvider (openai provider doesn't require Ollama; unreachable endpoint fails with the key hint and no Ollama error; unserved model fails listing alternatives). test_setup_ollama_guidance.py's SimpleNamespace stub gains provider="ollama".

Ollama-only behavior is unchanged when FO_PROVIDER is unset or ollama.

Notes / out of scope

• Saved profiles can't persist api_base_url / api_key (ModelPreset has no such fields), so non-Ollama users still need the FO_* env vars at runtime — which matches how get_model_configs() already resolves providers. Persisting provider settings in profiles would be a separate change.
• Endpoint probing is implemented for openai only; llama_cpp / mlx / claude get the env-driven framework and model names without a reachability check.
• Reproducing end-to-end on main also requires the circular-import fix in fix(core): break circular import between organize_options and config #1804, since fo currently fails at startup; the two changes are otherwise independent and the test suite passes on this branch alone.

Type of change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

• Manual: fo setup run --dry-run with the env vars above against a mock OpenAI-compatible server — valid key + served model → "Configuration is valid" with Framework openai, Text Model qwen3-14b-mlx; unserved model → validation error listing available models. Against real LM Studio with auth enabled and no key → "endpoint requires an API key; set FO_OPENAI_API_KEY".
• tests/core, tests/cli, tests/config, tests/integration/test_setup_wizard_core.py, tests/integration/test_cli_setup.py: 1948 passed, 2 skipped. Also ran tests/tui and tests/web on the combined change: passing.
• ruff check / ruff format --check on changed files: clean.
• mypy could not be run locally: it aborts on a syntax error inside the installed PyQt6 stubs (QtGui.pyi) before reaching project files — environment issue, unrelated to this change.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (none needed for existing FO_* vars; can add a setup note to the provider docs if wanted)
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules (n/a)

🤖 Generated with Claude Code

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}