[Feature] Add Command Code (api.commandcode.ai) as a provider — API-key + subscription OAuth flow

[rrmlima]

What are you trying to accomplish?

I want to use my Command Code Go subscription (or the paid Provider plan) as a provider inside OpenCodex, so Codex CLI/App can route to Command Code's model catalog (DeepSeek, Kimi, GLM, MiniMax, Qwen, Grok, etc.) through the same proxy — alongside the existing providers.

Command Code offers an official Provider API (OpenAI- and Anthropic-compatible) that is currently missing from the provider registry. It is especially valuable because Command Code subscriptions (Go/Pro plans) authenticate the CLI but do not include direct API access; the Provider plan ($15/mo, pay-as-you-go) unlocks the API. OpenCodex is the ideal place to expose it.

What prevents this today?

• The opencode-go provider in the registry (opencode.ai/zen/go/v1) is a different product (OpenCode Zen) and requires an API key — it is not the Command Code Provider API.
• There is no registry entry for Command Code (api.commandcode.ai/provider), so users must hand-roll a custom provider (ocx provider add commandcode --adapter openai-chat --base-url http://...) and, for subscriptions, run a local bridge (e.g. the hermes-commandcode-provider project) to convert the CLI login into an OpenAI-compatible endpoint.
• The subscription→API gap forces either a third-party bridge or the paid Provider plan, with no first-class support.

What should OpenCodex do?

1. Add a Command Code provider entry to the registry (id: "commandcode") using the openai-chat adapter pointed at https://api.commandcode.ai/provider/v1.
2. Support API-key auth (authKind: "key", dashboard URL https://commandcode.ai/studio/) for Provider-plan users.
3. Optionally support an OAuth/CLI-login flow (like kimi/xai/anthropic OAuth entries) via the CLI auth endpoint the CLI itself uses — so Go/Pro subscription holders can authenticate without a separate API key. Reference implementation: OmniRoute's command-code provider uses https://commandcode.ai/studio/auth/cli for the device/OAuth flow.
4. Seed the model catalog from the public GET /provider/v1/models endpoint, with per-plan filtering (403 MODEL_NOT_IN_PLAN for models outside the active plan).

Example usage or interface

# After implementation:
ocx login commandcode          # OAuth/CLI flow for subscription holders
# or
ocx provider add commandcode --api-key <CMD_API_KEY>   # Provider plan

# Codex then uses any Command Code model:
#   codex -m commandcode/deepseek/deepseek-v4-flash
#   codex -m commandcode/moonshotai/Kimi-K3

Registry entry sketch:

{
  id: "commandcode",
  label: "Command Code",
  adapter: "openai-chat",
  baseUrl: "https://api.commandcode.ai/provider/v1",
  authKind: "key",              // + optional oauthId for CLI-login flow
  dashboardUrl: "https://commandcode.ai/studio/",
  defaultModel: "deepseek/deepseek-v4-flash",
  liveModels: true,             // GET /provider/v1/models is public
}

Alternatives or workarounds

• Custom provider + local bridge (current workaround): run hermes-commandcode-provider (bridge on 127.0.0.1:8788 exposing /v1/chat/completions) and add it as a custom openai-chat provider with allowPrivateNetwork: true. Works, but adds a third-party daemon and manual model allowlisting.
• Provider plan + custom provider: ocx provider add commandcode --adapter openai-chat --base-url https://api.commandcode.ai/provider/v1 --api-key ... — works today, but no registry entry, no OAuth, no catalog seeding.

Additional context

• Upstream docs: https://commandcode.ai/docs/provider
  • POST https://api.commandcode.ai/provider/v1/chat/completions (OpenAI Chat Completions)
  • POST https://api.commandcode.ai/provider/v1/messages (Anthropic Messages)
  • GET https://api.commandcode.ai/provider/v1/models (public model list)
  • Auth: Authorization: Bearer <CMD_API_KEY> (same key as the CLI)
  • Errors: 403 upgrade_required (no Provider plan), 403 MODEL_NOT_IN_PLAN (model outside plan), 401 authentication_error
• Plans: Provider plan starts at $15/mo pay-as-you-go; Go/Pro subscription plans authenticate the CLI but need OAuth/bridge for API use.
• Model naming: upstream ids are namespaced (deepseek/deepseek-v4-flash, moonshotai/Kimi-K3, zai-org/GLM-5.2), which maps cleanly onto OpenCodex's <provider>/<model> namespace.
• Reference: OmniRoute already ships a commandCode provider with OAuth via https://commandcode.ai/studio/auth/cli (see its src/app/api/providers/command-code/ routes) — a good pattern to mirror.

[github-actions]

_{Automated translation bookkeeping — detected language: unknown.}

[Wibias]

[shipping-github] Opened PR #923 to address this.

[Wibias]

Thanks @rrmlima - fixed by PR #923 (ad4eb58b): Command Code is now a built-in key provider (ocx provider add commandcode) with live discovery of the public /provider/v1/models catalog, Bearer auth to https://api.commandcode.ai/provider/v1, and honest "unverifiable" key validation since the catalog is public. API-key (Provider plan) support is in; the optional OAuth/CLI-login flow remains a follow-up.