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

Activity

1. QiuShui-He

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Jul 6, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   safety-checkIssues related to safety and abuse checksIssues related to safety and abuse checks

   sandboxIssues related to permissions or sandboxingIssues related to permissions or sandboxing

   custom-modelIssues related to custom model providers (including local models)Issues related to custom model providers (including local models)

   on Jul 6, 2026
3. github-actions commented on Jul 6, 2026

   

   github-actionsbot

   on Jul 6, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • a big bug to report #30610

   Powered by Codex Action
4. amansman77 commented on Jul 9, 2026

   

   amansman77

   on Jul 9, 2026

   More actions

   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.

   👍React with 👍2Reacted by QiuShui-He and Zhe Chen
5. metrofun commented on Jul 31, 2026

   

   metrofun

   on Jul 31, 2026

   More actions

   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.
6. etraut-openai

   marked Auto-review uses invalid model name "codex-auto-review" #36094 as a duplicate of this issue on Aug 6, 2026
7. voski commented on Sep 24, 2026

   

   voski

   on Sep 24, 2026

   Last edited by voski

   More actions

   There is a workaround you can use.

   You need to supply your own model catalog which sets the auto review model override.

   Here is a sample prompt you can use and codex should be able to patch itself. Just set the target model to whichever one you want.

   Create a patched model catalog for my installed codex version.
   
   Copy the matching stock catalog, change only the `auto_review_model_override` from `null` to "gpt-5.6-sol". 
   
   Save it under `~/.codex/`. Then, set `model_catalog_json` to the patched catalog in `~/codex/config.toml`
   

   The drawback to this approach is that your catalog won't be up to date when you get a install a new version of codex. To fix that simply recreate the patch
8. zanwenfu commented on Sep 25, 2026

   

   zanwenfu

   on Sep 25, 2026

   More actions

   Running into this too, still happening as of Sep 25.

   I'm on Codex CLI v0.156.1 (macOS) with Azure OpenAI as a custom provider (wire_api = "responses") and approvals_reviewer = "auto_review". My main model is gpt-6-astra and it works fine, it's only auto review that breaks.

   Any command that needs escalation gets denied before it even runs. For me it was an scp upload to a test server:

   Automatic approval review failed: unexpected status 404 Not Found: The API deployment for this resource does not exist. ... url: https://<resource>.openai.azure.com/openai/v1/responses

   So the agent just sits there asking me to switch back to manual review lol. Looks like the same thing described in #31732, the reviewer sends codex-auto-review to Azure and Azure doesn't have it.

   Even just falling back to manual approval when the reviewer call fails would be a huge help. Happy to test a fix on Azure if that's useful!
9. voski commented on Sep 26, 2026

   

   voski

   on Sep 26, 2026

   More actions

   Running into this too, still happening as of Sep 25.

   I'm on Codex CLI v0.156.1 (macOS) with Azure OpenAI as a custom provider (wire_api = "responses") and approvals_reviewer = "auto_review". My main model is gpt-6-astra and it works fine, it's only auto review that breaks.

   Any command that needs escalation gets denied before it even runs. For me it was an scp upload to a test server:

   Automatic approval review failed: unexpected status 404 Not Found: The API deployment for this resource does not exist. ... url: https://<resource>.openai.azure.com/openai/v1/responses

   So the agent just sits there asking me to switch back to manual review lol. Looks like the same thing described in #31732, the reviewer sends codex-auto-review to Azure and Azure doesn't have it.

   Even just falling back to manual approval when the reviewer call fails would be a huge help. Happy to test a fix on Azure if that's useful!

   Did you attempt the fix I posted?
10. l33tdawg commented on Sep 29, 2026

    

    l33tdawg

    on Sep 29, 2026

    Last edited by l33tdawg

    More actions

    We hit this on the desktop app with DeepSeek (model_provider = "deepseek", wire_api = "responses", approvals_reviewer = "auto_review"). Two things that cost us a day, in case they help others:

    1. The catalog override only applies in a fresh app-server process. The desktop app talks to a daemon that survives app restarts, and the catalog is read once, at daemon start (same root cause as #47917). On our machine codex debug models showed "auto_review_model_override": "deepseek-flash", but reviews kept failing with The supported API model names are deepseek-flash, deepseek-v4-pro, but you passed codex-auto-review: the daemon had been running since before the override was written, and it still had the old catalog. Quitting and reopening the app does not restart the daemon. codex app-server daemon restart does, and escalations went through right after. So the workaround above needs one extra step: patch the catalog, then restart the daemon.

    2. The override is easy to lose. It lives on each model in the catalog, and anything that regenerates the file resets it. DeepSeek's own setup script writes auto_review_model_override: null for every model, so re-running it breaks auto-review again. A provider-level setting would survive that:

    [model_providers.deepseek]
    base_url = "https://api.deepseek.com/"
    wire_api = "responses"
    approval_review_model = "deepseek-flash"

    resolved before the built-in default, the way Amazon Bedrock already overrides approval_review_preferred_model() in-tree.

    We built that in a fork: config field in model-provider-info, one shared resolver used by the core guardian and the guardian-v2 reviewer paths, schema and thread-config proto updated, tests for the resolver and the guardian. It fixes the DeepSeek case with no catalog patching. Code PRs aren't accepted here, so the diff is ready if anyone wants it. Tell me where to put it.
11. wildcard

    added 2 commits that reference this issue on Oct 13, 2026

    docs(research): correct claims and add test plan after PR #1583 review

    ...

    d645dce

    fix: address cubic review of 2f8a17b on PR #1583

    ...

    489ae07