Client or integration
Codex App
Area
Proxy and routing
Summary
OpenCodex 2.8.0 still does not recognize Codex's internal approval model codex-auto-review as an OpenAI/Codex control-plane model.
When defaultProvider is a non-OpenAI provider, the model falls through the generic routing path and is sent unchanged to that provider. The provider rejects the unknown model, so an escalated command can fail before the approved command is spawned.
Expected behavior: codex-auto-review should route through the enabled canonical openai provider. If that provider is unavailable, routing should fail closed with NoEnabledOpenAiProviderError, rather than sending the internal model to an unrelated default provider.
This was previously reported in #637, but that issue was automatically closed only because it did not use the required template. The relevant v2.8.0 routing code remains unchanged.
Reproduction
- Configure an enabled canonical
openai provider in forward/account-pool mode.
- Configure a non-OpenAI provider such as DeepSeek.
- Set the non-OpenAI provider as
defaultProvider.
- Route Codex App through OpenCodex.
- Trigger an operation requiring the internal automatic approval review.
- Codex sends a request with
model: "codex-auto-review".
In src/router.ts, isBareOpenAiFamilyModel() recognizes only bare IDs beginning with gpt-, o1-, o3-, or o4-.
codex-auto-review:
- has no provider namespace;
- does not match the OpenAI-family prefix check;
- normally does not match a configured provider model/default;
- reaches the generic
defaultProvider fallback.
A minimal router regression test is:
const config = {
defaultProvider: "deepseek",
providers: {
openai: {
adapter: "openai-responses",
authMode: "forward",
codexAccountMode: "pool"
},
deepseek: {
adapter: "openai-chat",
baseUrl: "https://api.deepseek.com/v1",
defaultModel: "deepseek-chat"
}
}
};
expect(routeModel(config, "codex-auto-review").providerName).toBe("openai");
Current behavior selects deepseek.
Version
2.8.0 (tag v2.8.0, commit 1adad35731ff3586d3d8dfaf531d5b64e0bb1092); Codex CLI 0.146.0-alpha.9.2
Operating system
macOS 26.5.2
Provider and model
Canonical OpenAI forward provider plus DeepSeek default provider / codex-auto-review
Logs or error output
provider=deepseek
requestedModel=codex-auto-review
model=codex-auto-review
status=400
The upstream provider rejects codex-auto-review as an unsupported model.
The automatic approval review fails before the original command is spawned.
Redacted configuration
{
"providers": {
"openai": {
"adapter": "openai-responses",
"authMode": "forward",
"codexAccountMode": "pool"
},
"deepseek": {
"adapter": "openai-chat",
"baseUrl": "https://api.deepseek.com/v1",
"defaultModel": "deepseek-chat"
}
},
"defaultProvider": "deepseek"
}
Suggested fix
Use an exact internal-model allowlist before the generic provider/default fallback:
const CODEX_INTERNAL_OPENAI_MODELS = new Set(["codex-auto-review"]);
Resolve those IDs through the same canonical OpenAI branch used by bare OpenAI-family models. An exact allowlist is safer than a broad codex-* prefix because third-party providers may legitimately expose similarly named models.
Suggested regression cases:
- enabled canonical OpenAI + non-OpenAI default ->
codex-auto-review routes to openai;
- canonical OpenAI missing/disabled -> fail closed with
NoEnabledOpenAiProviderError;
- unknown non-internal model -> still uses
defaultProvider;
- normal DeepSeek routing remains unchanged.
Related: #637.
Checks
Client or integration
Codex App
Area
Proxy and routing
Summary
OpenCodex 2.8.0 still does not recognize Codex's internal approval model
codex-auto-reviewas an OpenAI/Codex control-plane model.When
defaultProvideris a non-OpenAI provider, the model falls through the generic routing path and is sent unchanged to that provider. The provider rejects the unknown model, so an escalated command can fail before the approved command is spawned.Expected behavior:
codex-auto-reviewshould route through the enabled canonicalopenaiprovider. If that provider is unavailable, routing should fail closed withNoEnabledOpenAiProviderError, rather than sending the internal model to an unrelated default provider.This was previously reported in #637, but that issue was automatically closed only because it did not use the required template. The relevant v2.8.0 routing code remains unchanged.
Reproduction
openaiprovider in forward/account-pool mode.defaultProvider.model: "codex-auto-review".In
src/router.ts,isBareOpenAiFamilyModel()recognizes only bare IDs beginning withgpt-,o1-,o3-, oro4-.codex-auto-review:defaultProviderfallback.A minimal router regression test is:
Current behavior selects
deepseek.Version
2.8.0 (tag
v2.8.0, commit1adad35731ff3586d3d8dfaf531d5b64e0bb1092); Codex CLI0.146.0-alpha.9.2Operating system
macOS 26.5.2
Provider and model
Canonical OpenAI forward provider plus DeepSeek default provider /
codex-auto-reviewLogs or error output
provider=deepseek requestedModel=codex-auto-review model=codex-auto-review status=400 The upstream provider rejects codex-auto-review as an unsupported model. The automatic approval review fails before the original command is spawned.Redacted configuration
{ "providers": { "openai": { "adapter": "openai-responses", "authMode": "forward", "codexAccountMode": "pool" }, "deepseek": { "adapter": "openai-chat", "baseUrl": "https://api.deepseek.com/v1", "defaultModel": "deepseek-chat" } }, "defaultProvider": "deepseek" }Suggested fix
Use an exact internal-model allowlist before the generic provider/default fallback:
Resolve those IDs through the same canonical OpenAI branch used by bare OpenAI-family models. An exact allowlist is safer than a broad
codex-*prefix because third-party providers may legitimately expose similarly named models.Suggested regression cases:
codex-auto-reviewroutes toopenai;NoEnabledOpenAiProviderError;defaultProvider;Related: #637.
Checks