fix(provider-wizard): allow multiple custom OpenAI-compatible providers

[Baran3575]

Problem

Issue #375: After setting up one custom OpenAI-compatible provider, configuring a second one is blocked. The wizard diverts to the Keep/Replace/Remove screen instead of allowing a new setup.

Root Cause

wizardProviderStoredKey matches saved providers by CatalogID. All generic/custom providers share the same CatalogID ("custom-openai-compatible" or "custom-anthropic-compatible"), so saving one creates a match that blocks creating another.

Fix

In advanceProviderWizard (internal/tui/provider_wizard_discovery.go), skip the ManageKey diversion for custom providers and route directly to the endpoint step. The user can:

• Overwrite an existing instance by re-entering the same base URL and name
• Create a new instance by entering a different base URL or name

Named providers (OpenAI, Anthropic, Groq, etc.) are unaffected — ManageKey is still shown for them.

Changes

File	Change
internal/tui/provider_wizard_discovery.go	+14 lines — skip ManageKey for custom providers
internal/tui/provider_wizard.go	0 lines — untouched
internal/tui/provider_wizard_test.go	+45 lines — 2 new tests

Testing

• TestAdvanceProviderWizardCustomSkipsManageKey — custom provider with saved key routes to Endpoint step, not ManageKey
• TestAdvanceProviderWizardNamedShowsManageKey — named provider with saved key still routes to ManageKey (no regression)
• All existing provider wizard tests pass (ManageKey remove, replace, keep, stored key matching)

Fixes #375

Summary by CodeRabbit

• Bug Fixes

  • Improved the provider setup wizard for accounts with saved credentials.
  • For non-OAuth providers where an endpoint is not required, the wizard now skips key management and proceeds directly to endpoint setup.
  • Model discovery is now started only when the wizard advances into the model-selection step.

• Tests

  • Added unit tests covering the custom-provider skip behavior and the named-provider key-management flow.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 578360ba-43e5-4179-a764-6d497fec3b38

📥 Commits

Reviewing files that changed from the base of the PR and between 0c98b59 and c174e3d.

📒 Files selected for processing (2)

• internal/tui/provider_wizard_discovery.go
• internal/tui/provider_wizard_test.go

🚧 Files skipped from review as they are similar to previous changes (2)

• internal/tui/provider_wizard_test.go
• internal/tui/provider_wizard_discovery.go

---

Walkthrough

The wizard now routes endpoint-based providers with stored keys directly past ManageKey and only starts model discovery when advancing into model setup. Tests cover both the custom-provider endpoint path and the named-provider ManageKey path.

Changes

Provider Wizard ManageKey Skip

Layer / File(s)	Summary
Endpoint-required routing logic internal/tui/provider_wizard_discovery.go	Adds a branch in advanceProviderWizard that skips ManageKey for non-OAuth, endpoint-required providers with a stored key, clears manageProviderName, advances directly to the endpoint step, and conditionally starts model discovery.
Routing behavior tests internal/tui/provider_wizard_test.go	Adds TestAdvanceProviderWizardCustomSkipsManageKey verifying custom providers skip ManageKey, and TestAdvanceProviderWizardNamedShowsManageKey verifying named providers still route to ManageKey.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• Gitlawb/zero#161: Changes the same provider wizard step-transition path and stored-key handling in advanceProviderWizard.
• Gitlawb/zero#168: Both PRs touch provider wizard model-discovery flow in provider_wizard_discovery.go.

Suggested reviewers: anandh8x, Vasanthdev2004

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main change: enabling multiple custom OpenAI-compatible providers.
Linked Issues check	✅ Passed	The code and tests address the issue by letting custom providers skip ManageKey and proceed to endpoint setup, restoring multi-provider configuration.
Out of Scope Changes check	✅ Passed	The added named-provider test and flow guard are directly related to the provider-wizard fix and do not introduce unrelated changes.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.}

[coderabbitai]

🧹 Nitpick comments (1)

internal/tui/provider_wizard_discovery.go (1)

45-67: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Duplicate advance/discovery branch in advanceProviderWizard. Clear manageProviderName here and let the shared advance() path handle the transition; the nested step == providerWizardStepModel check never fires on this path.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@internal/tui/provider_wizard_discovery.go` around lines 45 - 67, The
duplicate advance/discovery branch in advanceProviderWizard should be simplified
so the shared advance() flow handles the transition. In the
providerWizardStepProvider path, keep clearing providerWizard.manageProviderName
for endpoint-based providers, but remove the nested providerWizardStepModel
return/discovery check and rely on the existing step progression instead. Use
the advanceProviderWizard logic and providerWizard.advance() as the reference
points while preserving the current endpoint and manage-key behavior.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@internal/tui/provider_wizard_discovery.go`:
- Around line 45-67: The duplicate advance/discovery branch in
advanceProviderWizard should be simplified so the shared advance() flow handles
the transition. In the providerWizardStepProvider path, keep clearing
providerWizard.manageProviderName for endpoint-based providers, but remove the
nested providerWizardStepModel return/discovery check and rely on the existing
step progression instead. Use the advanceProviderWizard logic and
providerWizard.advance() as the reference points while preserving the current
endpoint and manage-key behavior.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: c6557893-008c-43e2-8f1f-b21d364522b4

📥 Commits

Reviewing files that changed from the base of the PR and between cdf9d83 and 34f6dc3.

📒 Files selected for processing (2)

• internal/tui/provider_wizard_discovery.go
• internal/tui/provider_wizard_test.go

[Vasanthdev2004]

This is the fix we're going with for #375 — I closed the duplicate #389 in favor of this one. Nice approach: gating at the call site in advanceProviderWizard (rather than changing the wizardProviderStoredKey lookup) keeps the lookup's meaning intact, and the table test over both custom transports plus the named-provider guard is exactly the right coverage.

Verified locally: go build ./... clean, and the wizard suite passes — re-selecting the generic "Custom OpenAI-compatible" entry with one already saved now routes to the endpoint step instead of trapping in keep/replace/remove, while a named provider (e.g. openai) still gets keep/replace/remove.

One thing before merge: the new test file isn't gofmt-clean and will trip the format check in CI. Please run:

gofmt -w internal/tui/provider_wizard_test.go

(It's just struct-field alignment on the step: field in the two new tests.)

One heads-up, not a blocker: because the wizard's provider list comes from providercatalog.All(), custom providers only ever appear as the single generic entry — so after this change there's no longer a wizard path to replace/remove an existing custom provider's stored key (the generic descriptor's name won't match a user's saved name). That's an acceptable trade to unblock multi-provider setup, and the old behavior could only manage the first CatalogID match anyway — just flagging it as a good follow-up (list saved custom instances for management).

Once the gofmt is in and CI goes green, this is good to merge. Thanks @Baran3575!

[gnanam1990]

Approving — this is the fix we're taking for #375.

Verified locally: go build ./..., go vet, and go test ./internal/tui are green, and the two added tests exercise the exact repro (a saved custom profile + re-selecting "Custom OpenAI-compatible" now routes to the Endpoint step instead of ManageKey) plus the regression boundary (a named provider still gets ManageKey). The change is localized to wizard navigation — it doesn't touch providerWizardProfile / UpsertProvider / mergeProvider, so an existing single custom-provider config resolves identically. Clean and well-scoped.

Note: this supersedes #389; I'm requesting changes there in favor of this one.

[Baran3575]

@gnanam1990 @Vasanthdev2004 is it possible to run action and review again?

[kevincodex1]

looks good to me!