Automatic approval review fails on Microsoft Foundry/Azure OpenAI because codex-auto-review is not deployable

What version of the Codex App are you using (From "About Codex" dialog)?

Version 26.506.31421 (2620)

What subscription do you have?

API key via Microsoft Foundry / Azure OpenAI-compatible endpoint.

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

Automatic approval review fails when Codex is configured to use a Microsoft Foundry / Azure OpenAI endpoint, then the action is rejected as high risk.

Observed local error, with the Azure resource name redacted:

Automatic approval review failed: unexpected status 404 Not Found: The API deployment for this resource does not exist. If you created the deployment within the last 5 minutes, please wait a moment and try again., url: https://[redacted-resource].openai.azure.com/openai/v1/responses

This looks like the Foundry/Azure equivalent of #19420. In that issue, codex-auto-review was missing for OpenAI API key users and a maintainer commented that it was fixed for API key users. However, the same automatic approval reviewer path still appears to fail for Microsoft Foundry / Azure OpenAI users.

The current Codex model catalog includes the hidden model:

{
  "slug": "codex-auto-review",
  "display_name": "Codex Auto Review",
  "description": "Automatic approval review model for Codex.",
  "visibility": "hide",
  "supported_in_api": true
}

For Azure/Foundry Responses API calls, the model parameter must refer to a deployed model/deployment name. Since codex-auto-review is not available/deployable in my Microsoft Foundry model catalog/resource, the automatic reviewer request appears to be sent to Azure with a model/deployment that does not exist. Regular Codex calls to explicitly deployed Azure/Foundry models work; the failure appears specific to the separate automatic approval review model.

What steps can reproduce the bug?

Configure Codex App to use an API key with a Microsoft Foundry / Azure OpenAI-compatible endpoint, for example an endpoint under https://<resource>.openai.azure.com/openai/v1/.
Use a deployed model for regular Codex requests.
Enable automatic approval review / the guardian automatic reviewer.
Trigger an action that requires automatic approval review, such as an apply_patch action that Codex classifies as high risk.
Observe that the automatic approval review request fails with Azure's "API deployment for this resource does not exist" 404, and Codex rejects the action.

What is the expected behavior?

Automatic approval review should either work for Microsoft Foundry / Azure OpenAI users or degrade to manual approval without treating the reviewer failure as an automatic high-risk denial.

Possible fixes:

Route automatic approval review through the configured/deployed model or a configurable reviewer model when using Azure/Foundry.
Expose a config override for the automatic approval review model.
Mark codex-auto-review as unsupported for Azure/Foundry/custom OpenAI-compatible providers and fall back to normal manual approval.
Document that automatic approval review requires a first-party OpenAI API key/model path if that is the intended limitation.

Additional information

Related issue: #19420 (codex-auto-review doesn't exist in the API), closed as fixed for OpenAI API key users on 2026-04-25.

Microsoft Foundry Responses API docs require a deployed Azure OpenAI model, and their examples say to replace the model value with the model deployment name. The Foundry model routing docs also state that the model parameter is the deployment name in most cases. That makes the current codex-auto-review routing incompatible unless Microsoft Foundry exposes/deploys that model slug or Codex uses a different reviewer model path for Azure/Foundry.

Please fix this...

Thanks for raising this issue. I completely agree with the suggestion to make the reviewer model configurable.

As a temporary workaround, you can resolve this by manually creating a deployment named codex-auto-review in Microsoft Foundry:

Go to Microsoft Foundry and select Deploy a base model.
Choose gpt-5.6-luna (or your preferred base model) and click Deploy.
Go to Custom settings.
Set the Deployment name explicitly to codex-auto-review.

Once deployed under this exact name, the automatic approval reviewer starts working as expected.
Hope this helps anyone encountering the same issue.

FWIW, here's a patch for this:

From 0a85e03489fa02af5fb6deef5565411417ce6473 Mon Sep 17 00:00:00 2001
From: Adriaan Moors <adriaanm@gmail.com>
Date: Thu, 17 Sep 2026 09:43:38 +0200
Subject: [PATCH] Fix Guardian model selection for command auth

---
 codex-rs/model-provider/src/provider.rs | 30 +++++++++++++++++--------
 1 file changed, 21 insertions(+), 9 deletions(-)

diff --git a/codex-rs/model-provider/src/provider.rs b/codex-rs/model-provider/src/provider.rs
index edeb748dc9..6f5b00a1cb 100644
--- a/codex-rs/model-provider/src/provider.rs
+++ b/codex-rs/model-provider/src/provider.rs
@@ -121,7 +121,7 @@ pub type ProviderAccountResult = std::result::Result<ProviderAccountState, Provi
 /// require a backend-specific model ID.
 pub const DEFAULT_APPROVAL_REVIEW_PREFERRED_MODEL: &str = "codex-auto-review";
 
-const API_KEY_APPROVAL_REVIEW_PREFERRED_MODEL: &str = "gpt-5.6-luna";
+const DIRECT_API_APPROVAL_REVIEW_PREFERRED_MODEL: &str = "gpt-5.6-luna";
 
 /// Default model used for memory extraction when a provider does not require a
 /// backend-specific model ID.
@@ -396,15 +396,17 @@ impl ModelProvider for ConfiguredModelProvider {
     }
 
     fn approval_review_preferred_model(&self) -> &'static str {
-        if self
-            .auth_manager
-            .as_ref()
-            .and_then(|auth_manager| auth_manager.auth_cached())
-            .is_some_and(|auth| auth.is_api_key_auth())
-        {
-            API_KEY_APPROVAL_REVIEW_PREFERRED_MODEL
-        } else {
+        let uses_codex_backend = provider_uses_first_party_auth_path(&self.info)
+            && self.info.supports_codex_backend_routes()
+            && self
+                .auth_manager
+                .as_ref()
+                .and_then(|auth_manager| auth_manager.auth_cached())
+                .is_none_or(|auth| auth.uses_codex_backend());
+        if uses_codex_backend {
             DEFAULT_APPROVAL_REVIEW_PREFERRED_MODEL
+        } else {
+            DIRECT_API_APPROVAL_REVIEW_PREFERRED_MODEL
         }
     }
 
@@ -749,6 +751,16 @@ mod tests {
         assert_eq!(provider.approval_review_preferred_model(), "gpt-5.6-luna");
     }
 
+    #[test]
+    fn configured_provider_uses_luna_for_approval_review_with_command_auth() {
+        let provider = create_model_provider(
+            provider_info_with_command_auth(),
+            /*auth_manager*/ None,
+        );
+
+        assert_eq!(provider.approval_review_preferred_model(), "gpt-5.6-luna");
+    }
+
     #[test]
     fn configured_provider_uses_default_approval_review_model_with_chatgpt_auth() {
         let provider = create_model_provider(
-- 
2.54.0

Reproduced with an internal LLM gateway (not Azure): auto-review sends codex-auto-review, which the gateway does not expose as a model or alias, producing a 404 and fail-closed denial. This applies to any compatible gateway without that special identifier.

The proposed patch improves command-auth routing, but hardcoding gpt-5.6-luna is still too narrow: a gateway may expose neither that model nor codex-auto-review. Auto-approval needs provider-aware reviewer selection, a dedicated auto-review model override, or a safe fallback to manual approval.

Same issue here with Codex CLI 0.162.1, using Azure Foundry with API-key authentication.

Regular requests work, but automatic approvals fail because the reviewer requests gpt-5.6-luna, which isn’t deployed in my resource. Confirmed from the actual request logs:

model_client.stream_responses_api{model=gpt-5.6-luna ... api.path="/responses"}

I had created a deployment named codex-auto-review for the previous behavior. That no longer satisfies these requests.

I can deploy GPT-6 Luna under the name gpt-5.6-luna, but giving a newer model an older model’s name is a confusing workaround. Maintaining a custom model catalog also seems disproportionate just to choose the reviewer deployment.

Adding another vote for a provider-level automatic-review model setting, and a human-approval fallback when the reviewer request fails. Following this issue for updates.

Navigation Menu

Repository navigation

Automatic approval review fails on Microsoft Foundry/Azure OpenAI because codex-auto-review is not deployable #21928

What version of the Codex App are you using (From "About Codex" dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Automatic approval review fails on Microsoft Foundry/Azure OpenAI because codex-auto-review is not deployable #21928

Description

What version of the Codex App are you using (From "About Codex" dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

joseph-schwartz commented on Jul 30, 2026

hanohrs commented on Aug 4, 2026

adriaanm commented on Sep 17, 2026

danbarr commented on Sep 18, 2026

k-thornton commented on Oct 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions