[Bug]: codex-auto-review still falls through to a non-OpenAI default provider in v2.8.0 #816

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

1. Configure an enabled canonical openai provider in forward/account-pool mode.
2. Configure a non-OpenAI provider such as DeepSeek.
3. Set the non-OpenAI provider as defaultProvider.
4. Route Codex App through OpenCodex.
5. Trigger an operation requiring the internal automatic approval review.
6. 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:

1. enabled canonical OpenAI + non-OpenAI default -> codex-auto-review routes to openai;
2. canonical OpenAI missing/disabled -> fail closed with NoEnabledOpenAiProviderError;
3. unknown non-internal model -> still uses defaultProvider;
4. normal DeepSeek routing remains unchanged.

Related: #637.

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.