[ENHANCEMENT] CLI: inherit providers and configuration from the main app

[martin-rueegg]

Problem (one or two sentences)

The Roo Code CLI only supports five hard-coded providers — Anthropic, OpenAI, Gemini, OpenRouter, and Vercel AI Gateway — even though the full Roo Code app supports ~35. Users who already hold direct credentials for DeepSeek, Mistral, xAI, Qwen, and others cannot use them from the CLI, forcing them through OpenRouter or off the CLI entirely.

Context (who is affected and when)

Automation-focused developers and CLI-first users who have API keys for a provider that is not in the CLI's shortlist. This bites immediately when someone runs roo --provider deepseek ... (rejected as invalid) or wants to point an OpenAI-compatible client at their own endpoint.

Desired behavior (conceptual, not technical)

The CLI should accept every provider the main app supports, and let users supply that provider's API key, model, and (where relevant) endpoint — without the CLI maintaining its own separate provider list.

Constraints / preferences

• No duplicated provider definitions; reuse the single source of truth already in the shared types package.
• Keep the existing flags ergonomic: --provider, --api-key, -m/--model; add a --base-url for providers whose endpoint differs.
• The existing five providers must keep working unchanged.

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Acceptance criteria

Given a built CLI:

• When I run roo --provider deepseek -m deepseek-chat --base-url https://api.deepseek.com -k sk-... "hello", then the CLI targets DeepSeek's API directly (no OpenRouter).
• When I run roo --provider <any provider known to the main app>, then it is accepted without a hard-coded allowlist.
• When I use the existing five providers, then behavior is unchanged.
• But when I pass an unknown provider id, then the CLI still rejects it with a clear error listing valid values.

Proposed approach

Replace the CLI's hand-maintained supportedProviders, envVarMap, and the getProviderSettings switch with the shared registry (providerNames, isProviderName, providerDefinitionList) from @roo-code/types. For the active provider, populate its own settings fields (API key, base URL, model id) from its settingsShape, and add an optional --base-url flag that writes to that provider's base-URL field. Optionally attach envVar/defaultBaseUrl metadata to ProviderDefinition so env-var lookup is also data-driven.

Trade-offs / risks

• A few providers require extra inputs beyond key/model/base URL (e.g. Kimi Code auth method, OpenAI Codex service tier, Z.AI API line); these can be opt-in flags rather than fully generic.
• Dynamic providers normally fetch remote model lists; the CLI's -m pass-through sidesteps that but may accept model ids the endpoint rejects.
• Extending the shared ProviderDefinition type touches the VS Code extension too, so any new fields must be optional/additive.

[martin-rueegg]

Action Plan: CliProviderInheritance v1.0: inherit provider registry

Discussion

The main app centralizes provider knowledge in @roo-code/types: providerDefinitionList registers ~35 providers, each a ProviderDefinition carrying apiProvider, a Zod settingsShape (API key, base URL, model id, …), modelIdKey, and getModelId. provider-settings.ts exposes providerNames, isProviderName, providerNamesSchema, and getModelId. The extension bundle already implements every handler in src/api/providers/*.

The CLI ignores all of that and re-implements a 5-provider subset: supportedProviders/SupportedProvider in apps/cli/src/types/types.ts, a 5-entry envVarMap + manual getProviderSettings switch in apps/cli/src/lib/utils/provider.ts, a validation gate in apps/cli/src/commands/cli/run.ts, and per-provider model-key handling in apps/cli/src/lib/utils/context-window.ts. The settings the CLI builds flow into RooCodeSettings in apps/cli/src/agent/extension-host.ts, which the full extension consumes.

The goal is to make the CLI inherit the shared registry and configuration instead of maintaining its own list. This unlocks every provider (notably DeepSeek, which already declares deepSeekApiKey/deepSeekBaseUrl/apiModelId in deepseek.ts) for free.

Analysis

What changes

Area	Change
apps/cli/src/types/types.ts	Drop supportedProviders/SupportedProvider; use shared ProviderName + isProviderName
apps/cli/src/lib/utils/provider.ts	Replace envVarMap + getProviderSettings switch with data-driven construction from the active ProviderDefinition.settingsShape
apps/cli/src/index.ts / run.ts	Add --base-url flag; validate provider via isProviderName; pass base URL through
packages/types/src/provider-settings/common.ts	Optionally add envVar/defaultBaseUrl metadata to ProviderDefinition (additive)
apps/cli/src/lib/utils/context-window.ts	Simplify model-id-key mapping via shared getModelId/modelIdKeysByProvider
apps/cli/README.md, apps/cli/CHANGELOG.md	Document provider/env-var/--base-url; changelog entry

Scope

• In: inherit the provider registry for --provider validation, settings construction, and base-URL/key/model mapping; add --base-url; enable all shared providers.
• Out: implementing new inference handlers (they already exist), provider-specific UX for exotic auth flows, and remote model-list fetching (the CLI keeps -m pass-through).

Implementation Plan

Block 1 — Replace the provider allowlist with the shared registry

• Remove supportedProviders/SupportedProvider/isSupportedProvider from apps/cli/src/types/types.ts; type FlagOptions.provider/CliSettings.provider as ProviderName.
• In run.ts, validate with isProviderName and report valid values from providerNames.

Verification: npx tsc --noEmit and the existing types/run suites pass; --provider deepseek is no longer rejected by the gate.

Block 2 — Data-driven provider settings

• Rewrite provider.ts to resolve the active ProviderDefinition and write the provider's own fields (API key, base URL, model id) into RooCodeSettings via its settingsShape keys — replacing the manual switch.

Verification: updated provider.test.ts green; a DeepSeek case produces deepSeekApiKey/deepSeekBaseUrl/apiModelId; the five existing providers produce the same fields as before.

Block 3 — --base-url flag

• Add the option in index.ts, the FlagOptions field, run.ts wiring, and map it to the active provider's base-URL setting in provider.ts.

Verification: roo --help lists --base-url; a unit test asserts it lands in the provider's base-URL field.

Block 4 — Optional provider metadata in shared types

• Extend ProviderDefinition with optional envVar/defaultBaseUrl (additive) in common.ts; backfill for the existing providers; use it for env-var resolution in the CLI.

Verification: packages/types suites pass; extension type-check unaffected.

Block 5 — Remove remaining per-provider special cases

• Simplify context-window.ts using shared getModelId/modelIdKeysByProvider; fix any list/onboarding code that assumes the 5-provider set.

Verification: full apps/cli Vitest suite green; list/onboarding tests pass.

Block 6 — Docs and changelog

• Update README.md (provider/env-var table, --base-url, DeepSeek example) and add an Unreleased entry to CHANGELOG.md.

Verification: docs render; changelog reflects the change.

Proposed commit message

feat(cli): inherit provider registry and configuration from shared types

- Replace hard-coded supportedProviders with providerNames/isProviderName
- Build provider settings from the active provider definition's settings shape
- Add --base-url flag mapped to the active provider's base URL field
- Extend ProviderDefinition with optional envVar/defaultBaseUrl metadata
- Enable all shared providers (DeepSeek, Mistral, xAI, Qwen, ...) in the CLI

Change History

Version	Date	Description
v1.0	2026-08-14	Initial AP