Skip to content

fix(cli): keep openai passthrough during ocx init so gpt-* models still route (issue #261) - #262

Merged
lidge-jun merged 2 commits into
lidge-jun:devfrom
Wibias:codex/improve-no-provider-error
Jul 22, 2026
Merged

fix(cli): keep openai passthrough during ocx init so gpt-* models still route (issue #261)#262
lidge-jun merged 2 commits into
lidge-jun:devfrom
Wibias:codex/improve-no-provider-error

Conversation

@Wibias

@Wibias Wibias commented Jul 22, 2026

Copy link
Copy Markdown
Collaborator

Summary

Fixes the root cause behind #261.

The reporter selected Kimi as their default provider, then every built-in gpt-* request 404'd with No enabled canonical OpenAI provider for model: gpt-5.6-sol.

Root cause

ocx init assembled the saved config by spreading the defaults and then replacing the whole providers map with just the chosen provider:

s const config = { ...getDefaultConfig(), providers: { [providerName]: providerConfig }, // wipes the baseline openai passthrough defaultProvider: providerName, };

The default config ships an openai forward provider that passes Codex's ChatGPT login through to the backend. The router sends every bare gpt-* model straight to providers["openai"] regardless of defaultProvider:

s if (isBareOpenAiFamilyModel(modelId)) { const provider = config.providers[OPENAI_CODEX_PROVIDER_ID]; // "openai" if (provider && provider.disabled !== true) return routeResult(...); throw new NoEnabledOpenAiProviderError(modelId); // 404 }

So the moment ocx init dropped the openai provider, gpt-* routing broke. The default being Kimi was a red herring; the passthrough deletion was the actual bug.

Fix

  1. buildInitConfig (extracted, pure, tested) now layers the chosen provider on top of the baseline defaults instead of replacing them, so the openai passthrough survives.
  2. ocx init prints a note when a non-openai default is chosen, so users know gpt-* still routes through their ChatGPT login.
  3. Clearer prompts: "Choose your default provider (you can add more later):" and "Select default provider (number):".
  4. More actionable error message on NoEnabledOpenAiProviderError as a safety net for configs that still end up without an openai provider.

Changes

  • src/cli/init.ts: Preserve baseline providers, extract buildInitConfig, add note, clarify prompts
  • src/router.ts: Actionable NoEnabledOpenAiProviderError message
  • tests/init-config.test.ts: Cover passthrough preservation, openai-as-default, and port

Verification

  • bun test on init-config, startup-prompt, router: 26 pass, 0 fail
  • bun run typecheck: clean

Wibias added 2 commits July 22, 2026 07:51
Add actionable guidance to the error message: tell users to run 'ocx init' or check their config. The previous message was technical and did not help users who had not configured a provider yet (issue lidge-jun#261).
…tion

The previous wording ('Available providers' / 'Select provider') made it seem like the user was enabling all providers rather than choosing a default. Updated to 'Choose your default provider (you can add more later)' and 'Select default provider (number)' per user feedback on issue lidge-jun#261.
@Wibias Wibias changed the title fix(router): improve error message when no OpenAI provider is configured fix(cli): improve provider selection UX and error messaging Jul 22, 2026
@lidge-jun
lidge-jun merged commit 04dfc7f into lidge-jun:dev Jul 22, 2026
9 checks passed
@Wibias Wibias changed the title fix(cli): improve provider selection UX and error messaging fix(cli): keep openai passthrough during ocx init so gpt-* models still route (issue #261) Jul 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants