Bug: auto-review uses hardcoded model name "codex-auto-review", incompatible with custom providers

Open 💬 8 comments Opened May 28, 2026 by yunghao416-sys

Environment

Codex Version: Codex Desktop (macOS)
Provider: Custom model provider (DeepSeek v4), base_url = "http://localhost:3000/v1"

Configuration (`config.toml`)

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

[model_providers.custom]
name = "custom"
wire_api = "responses"
requires_openai_auth = true
base_url = "http://localhost:3000/v1"

Issue Description

When using a custom model provider (e.g., DeepSeek), Codex's sandbox auto-review feature sends requests to the configured base_url, but the model field in the request is hardcoded as "codex-auto-review" instead of using the model name configured in config.toml.

Since custom providers (e.g., DeepSeek API) only recognize deepseek-v4-pro / deepseek-v4-flash, the request is rejected:

"error":{"message":"The supported API model names are deepseek-v4-pro or deepseek-v4-flash,
but you passed codex-auto-review.","type":"invalid_request_error"}

Impact

All require_escalated sandbox commands (e.g., git clone, network requests, etc.) fail to pass auto-review, even when the commands themselves are safe.

Expected Behavior

The auto-review feature should use the model name configured by the user (the model field in config.toml), or allow users to separately specify which model auto-review should use in the configuration.

Workaround

Insert a middleware proxy in front of the Codex internal proxy (ccx-darwi:3000) to map codex-auto-review to the user-configured model name.

View original on GitHub ↗

8 Comments

JunJieLiu51520 · 3 months ago

I'd like to work on this. The root cause is a hardcoded model name string used in the auto-review request path — I'll trace the exact location and propose a fix that falls back to the user-configured model name.

Will share full analysis shortly. Happy to submit a PR if the team would like me to implement this.

JunJieLiu51520 · 3 months ago

Root cause & fix

Root cause

In codex-rs/core/src/guardian/review.rs, the function run_guardian_review_session sources the model ID exclusively from turn.provider.approval_review_preferred_model(), which returns the compile-time constant "codex-auto-review" (defined in codex-rs/model-provider/src/provider.rs). The user's configured model field is never consulted for auto-review requests.

Fix

Check turn.config.review_model first (an Option<String> from the loaded config), and fall back to the provider default only when it's not set:

-let preferred_model_id = turn.provider.approval_review_preferred_model();
+let preferred_model_id = turn
+    .config
+    .review_model
+    .as_deref()
+    .unwrap_or_else(|| turn.provider.approval_review_preferred_model());

This allows users to either:

Set review_model = "deepseek-v4-pro" in config.toml to explicitly control the auto-review model, or
Leave it unset to fall back to the existing provider default

My fork branch with the implementation: fix/24879-auto-review-model-name

Happy to submit a PR if the team would like me to implement this.

Gogoal-L · 2 months ago

same

limex · 2 months ago

ViCrack · 1 month ago

vTuanpham · 1 month ago

+1 This is dumb, why force user into a costly model just for command review without giving the option to a smaller variant or custom model ?

xznhj8129 · 1 month ago

+1; this is a serious problem for me as it consumes well over 50% of my usage; i want to route it to a local 27B model instead

metrofun · 27 days ago

Until Codex supports a separate review model, you can work around this with a
local gateway. The idea is: keep your normal model unchanged, but route
Codex's hard-coded codex-auto-review model name to deepseek-v4-pro.

Install Swobu and start it.

Create a codex workspace with two routes:

| Route | Backend model | Base URL | Protocol |
|---|---|---|---|
| deepseek-v4-pro | deepseek-v4-pro | http://localhost:3000/v1 | Responses |
| codex-auto-review | deepseek-v4-pro | http://localhost:3000/v1 | Responses |

Then point Codex at the 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 local Swobu endpoint. If the backend
expects authentication, configure it on both Swobu targets.

I tested this path: Codex sends model: "codex-auto-review" to Swobu, and Swobu
forwards the request to the backend as model: "deepseek-v4-pro".

This does not fix the limitation in Codex; it only remaps the fixed model name.
The backend must still support the Responses API behavior used by auto-review.

Disclosure: I maintain Swobu. Glad to help with any Swobu-specific failure at
github.com/swobuforge/swobu