feat(ai): add Command Code provider#3298
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1eeaf95bec
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| ...(apiKey && { | ||
| fetchDynamicModels: () => | ||
| fetchOpenAICompatibleModels({ | ||
| api: "openai-completions", |
There was a problem hiding this comment.
Route Claude models to the Anthropic endpoint
When the live Command Code catalog includes Anthropic/Claude models, this normalizes every entry as openai-completions, so selecting a model such as commandcode/claude-sonnet-4-6 will be sent to /provider/v1/chat/completions. The Command Code Provider API documents that Anthropic models use /provider/v1/messages and that the wrong endpoint returns 400, so these catalog entries need to be detected and emitted as anthropic-messages with the matching base URL.
Useful? React with 👍 / 👎.
roboomp
left a comment
There was a problem hiding this comment.
P3: not reviewable as-is. The PR claims a 12-file packages/ai provider addition, but the checked-out diff has no merge base with origin/main and rewrites 3,831 files, including release metadata and CI.
There is also already an open Command Code provider PR (#2936) with the same scope.
Provider-specific code has convention issues (await import() dispatch paths, type assertion/Parameters<>) that should be cleaned up after the branch is re-cut.
Thanks for contributing the provider integration.
| resolver = "3" | ||
|
|
||
| [workspace.package] | ||
| version = "15.1.3" |
There was a problem hiding this comment.
blocking: this branch downgrades the workspace package version from 16.1.16 on origin/main to 15.1.3. A provider addition must not roll back release metadata; this is a symptom of the branch carrying an old repo snapshot instead of the claimed provider-only change.
| binary_path: packages/coding-agent/binaries/omp-darwin-arm64, | ||
| } | ||
| - { | ||
| os: windows-latest, |
There was a problem hiding this comment.
blocking: this CI rewrite is unrelated to adding the Command Code provider. The checked-out diff spans 3,831 files (git diff --stat origin/main HEAD: +117,153/-879,793) while the PR body claims 12 packages/ai files; this needs to be rebased/re-cut to only the provider changes before it is reviewable.
| return; | ||
| } | ||
| case "commandcode": { | ||
| const { loginCommandCode } = await import("./utils/oauth/commandcode"); |
There was a problem hiding this comment.
should-fix: repo rules forbid inline/dynamic import(); provider login modules should be imported at top level. This adds another dynamic import path in AuthStorage.login, so compiled/static analysis and convention checks stay inconsistent.
| } | ||
|
|
||
| case "commandcode": { | ||
| const { loginCommandCode } = await import("./utils/oauth/commandcode"); |
There was a problem hiding this comment.
should-fix: same dynamic-import issue in the headless login dispatch. Please make loginCommandCode a top-level import rather than adding await import() inside the switch.
| const apiKey = config?.apiKey; | ||
| const baseUrl = config?.baseUrl ?? "https://api.commandcode.ai/provider/v1"; | ||
| const references = createBundledReferenceMap<"openai-completions">( | ||
| "commandcode" as Parameters<typeof getBundledModels>[0], |
There was a problem hiding this comment.
should-fix: this uses both a type assertion and Parameters<>, which the repo conventions ban as type hacks. Export/import the concrete provider-id type or extend the bundled-model key type instead of casting `
Add "Command Code" as a first-party provider accessible via `/login commandcode`. Command Code's official Provider API is OpenAI-compatible (https://api.commandcode.ai/provider/v1), so this is a conventional OpenAI-compatible API-key provider — no custom protocol port. - KnownProvider/OAuthProvider unions + PROVIDER_DESCRIPTORS catalog entry - commandCodeModelManagerOptions: runtime discovery via GET /v1/models, modeled on vLLM (not on models.dev, so no models.json regeneration) - createApiKeyLogin flow wired into both interactive (auth-storage) and headless (pi-ai cli) login dispatch + refresh-token group - serviceProviderMap entry so COMMANDCODE_API_KEY env var resolves for discovery and streaming - dispatch regression test Reference plugin: https://github.com/KRoperUK/command-code-go-pi-provider (that targets the separate /alpha/generate CLI endpoint — intentionally not ported; the OpenAI-compat Provider API is the documented public path).
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8beadd5c68
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| defaultModel: "deepseek/deepseek-v4-pro", | ||
| envVars: ["COMMANDCODE_API_KEY"], | ||
| createModelManagerOptions: (config: ModelManagerConfig) => commandCodeModelManagerOptions(config), | ||
| catalogDiscovery: { label: "Command Code", oauthProvider: "commandcode" }, |
There was a problem hiding this comment.
Keep runtime-only Command Code out of generation
This catalogDiscovery opt-in enrolls Command Code in packages/catalog/scripts/generate-models.ts's catalog fetch loop (isCatalogDescriptor && !DISCOVERY_ONLY_PROVIDERS). Because this provider is described as runtime-discovered and has no bundled models.json source, a maintainer who has COMMANDCODE_API_KEY set will bake the live /provider/v1/models response into generated models.json on the next regeneration instead of keeping it runtime-only. Either mark it discovery-only in the generator or remove this catalog-discovery opt-in.
Useful? React with 👍 / 👎.
| ### Added | ||
|
|
||
| - Added the **Command Code** provider (`/login commandcode`), backed by Command Code's OpenAI-compatible Provider API (`https://api.commandcode.ai/provider/v1`). Models are discovered at runtime from `GET /provider/v1/models`; authenticate by pasting a key (Command Code Studio → API Keys) or setting `COMMANDCODE_API_KEY`. Follows the same shape as other OpenAI-compatible API-key providers (Cerebras, Moonshot, Together, vLLM). |
There was a problem hiding this comment.
Remove the duplicate released changelog entry
This same Command Code note is already under [Unreleased], but this copy was inserted under the already-released [15.1.4] - 2026-05-19 section; the repo changelog rules say released sections are immutable. Leaving it here rewrites historical release notes and makes the provider appear to have shipped in an old release, so this duplicate should be removed from the released section.
Useful? React with 👍 / 👎.
|
Closing — re-cut from current main as a clean cherry-pick with only 8 provider-specific files. The original branch had a 3,831-file diff from an old fork point. New PR will reference this issue. |
Summary
Adds Command Code as a first-party provider users can log in with via
/login commandcode, then use all its models.Command Code's official Provider API is OpenAI-compatible (docs):
POST https://api.commandcode.ai/provider/v1/chat/completions,GET /provider/v1/models,Authorization: Bearer <key>. So this is a conventional OpenAI-compatible API-key provider (same shape as Cerebras / Moonshot / Together / vLLM) — no custom protocol port.Changes (12 files,
packages/ai)commandcodeadded to theKnownProvider/OAuthProviderunions; acatalogDescriptorentry inPROVIDER_DESCRIPTORS(oauthProvider: "commandcode", envCOMMANDCODE_API_KEY).commandCodeModelManagerOptionsmodeled onvllmModelManagerOptions— runtime discovery againstGET /provider/v1/models. Not on models.dev, so nomodels.jsonregeneration needed (uses the sameas Parameters<typeof getBundledModels>[0]cast as vLLM).createApiKeyLoginflow (utils/oauth/commandcode.ts) wired into the interactive dispatch (auth-storage.ts), the headlesspi-ai loginswitch (cli.ts), the built-in OAuth provider list, and the API-key refresh-token group (oauth/index.ts).serviceProviderMapentry soCOMMANDCODE_API_KEYresolves for discovery + streaming +auth-broker migrate --include-env(without it, env-var users got a silent no-auth failure).auth-storage-api-key-login.test.ts.packages/aiCHANGELOG[Unreleased].Verification
bun run check:types(tsgo) — passes.bun run lint— the changed lines add zero diagnostics (20 pre-existinguseOptionalChainwarnings elsewhere are untouched and out of scope).PROVIDER_DESCRIPTORS+getOAuthProviders()includecommandcode;getEnvApiKey("commandcode")resolvesCOMMANDCODE_API_KEY;listProvidersWithEnvKey()includes it.expect()s, 0 errors). Tests are marked failed locally only due to a pre-existing WindowsEBUSYin the sharedafterEachfs.rm(tempDir)— confirmed identical onmainwith this branch stashed; CI runsubuntu-22.04where it is green.serviceProviderMap) is fixed above.Reference: https://github.com/KRoperUK/command-code-go-pi-provider