auto-review fails with "codex-auto-review" model name not supported

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #30610

Powered by Codex Action

Hit the same issue independently (Azure OpenAI custom model_provider instead of a DeepSeek-compatible one, but same underlying symptom — the guardian sends the literal codex-auto-review model id to a backend that has no such deployment/model, the review call 404s/400s, and since the guardian fails closed on any review error, the underlying action gets denied as "unacceptable risk" instead of surfacing the real cause).

Root cause: codex-rs/core/src/guardian/review.rs, guardian_review_session_config already has fallback logic to use the active session's real model when the preferred review model (codex-auto-review) isn't available — but the fallback never triggers for custom providers, because the model catalog it checks against (ModelsManager::list_models) is filtered by auth mode/visibility only, not by whether the active provider can actually serve that specific model id. codex-auto-review is a visible catalog entry for API-key auth in general, so the lookup succeeds even when the active provider (Azure, DeepSeek-compatible, etc.) has no such model, and the literal id gets sent upstream.

let default_review_model_id = turn.provider.approval_review_preferred_model(); // "codex-auto-review" unless overridden
let model_override = turn.model_info.auto_review_model_override.as_deref();
let review_model_id = model_override.unwrap_or(default_review_model_id);
let review_model = available_models
    .iter()
    .find(|preset| preset.model == review_model_id);

Suggested fix — only trust the catalog match for the default preferred model when the provider is actually OpenAI-hosted (same signal already used for gating image_generation_runtime_enabled in codex-rs/core/src/tools/spec_plan.rs); always honor an explicit auto_review_model_override:

let provider_can_serve_preferred_review_model = model_override.is_some()
    || turn.provider.info().uses_openai_actor_authorization()
    || (turn.provider.info().requires_openai_auth
        && turn
            .auth_manager
            .as_deref()
            .is_some_and(AuthManager::current_auth_uses_codex_backend));
let review_model = provider_can_serve_preferred_review_model
    .then(|| {
        available_models
            .iter()
            .find(|preset| preset.model == review_model_id)
    })
    .flatten();

Verified locally against an Azure OpenAI custom provider: sandbox escalation approvals that previously failed closed with a 404 for codex-auto-review now correctly fall back to the active session's real model and succeed.

Full write-up (environment, repro, root cause, fix) in #31732 — closing that one as a duplicate of this issue since this was filed first. Happy to open a PR for the fix above if invited.

For the DeepSeek setup in the original report, you can keep your normal model
unchanged and route Codex's fixed codex-auto-review name to
deepseek-v4-pro through a local gateway.

Install Swobu and create a codex
workspace with these two explicit Responses routes:

| Route | Backend model | Backend URL |
|---|---|---|
| deepseek-v4-pro | deepseek-v4-pro | your DeepSeek-compatible /v1 URL |
| codex-auto-review | deepseek-v4-pro | the same /v1 URL |

Then point Codex at that workspace in ~/.codex/config.toml:

model = "deepseek-v4-pro"
model_provider = "swobu"

[model_providers.swobu]
name = "Swobu"
wire_api = "responses"
base_url = "http://127.0.0.1:7926/c/codex/v1"

Codex does not need an API key for the loopback Swobu endpoint. Configure any
real backend credential on both Swobu targets.

I reproduced this route: Codex's model: "codex-auto-review" request reached
the backend as model: "deepseek-v4-pro".

This is a gateway workaround, not a Codex fix. The backend must support the
Responses behavior used by auto-review. I have not tested the Azure deployment
configuration mentioned later in this thread, and this does not apply to the
first-party Responses-Lite failure reported in other issues.

Disclosure: I maintain Swobu. If you try this, please share the result. For a
Swobu-specific failure, include the error and backend setup at
github.com/swobuforge/swobu, and I will
help investigate.