Auto-review appears to fall back to Sol low through OpenCodex; direct ChatGPT login uses codex-auto-review

Start with src/adapters/openai-responses/passthrough.ts and src/lib/provider-client-headers.ts at v2.80.0: check whether x-codex-guardian or equivalent reviewer markers survive forwarding on HTTP and WebSocket paths, and whether the generated catalog entry for codex-auto-review (visibility hide, in opencodex-catalog.json) would satisfy Codex's select_review_model lookup. Then trace the /v1 base-URL handling against the supports_codex_backend_routes() logic referenced in the issue. Done looks like a definitive answer to whether the proxied path sends codex-auto-review or an already-resolved task model, backed by per-request capture, plus a fix or a documented non-issue.

Client or integration

Codex App

Area

Proxy and routing

Summary

I sign in to Codex with a ChatGPT account and have Auto-review enabled.

While using Codex through OpenCodex, the relevant call statistics I inspected showed GPT-6.1 Sol / low. After disabling the OpenCodex integration and restoring native Codex direct access, the records showed codex-auto-review / low.

An old explicit reviewer-model override is not still enabled:

• auto_review_model is commented out and inactive.
• I checked the model catalog; the relevant auto_review_model_override fields are empty/unset.
• Auto-review remains enabled, with approval policy on-request and sandbox mode workspace-write.

Connection	Observed model identifier or display name	Reasoning effort	Calls	Total tokens
Through OpenCodex, before disabling the integration	GPT-6.1 Sol	low	853	95,481,177
Native Codex direct access after disabling OpenCodex	codex-auto-review	low	2	140,189

These totals cover different observation periods. They are not a controlled cost or performance comparison using identical workloads. Per-request evidence attributing all 853 records to approval reviews has not yet been attached; low effort alone must not be used to classify ordinary inference requests as Guardian requests.

This report concerns a difference in reviewer-model selection or identification between the proxied and direct paths. I am not claiming that all 95,481,177 tokens were incorrectly charged against my weekly allowance.

Expected behavior

With ChatGPT account authentication and no reviewer-model override, OpenCodex should preserve Codex's official default Auto-review behavior and request semantics, rather than unintentionally falling back to an ordinary task model because of a missing catalog entry or an integration compatibility issue.

OpenAI's documentation states that Auto-review safety checks are free and do not count against plan usage limits when signed in with ChatGPT:

https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan

The observed difference may therefore affect the official free Auto-review path and warrants investigation. I do not have per-request server-side billing evidence, so the actual billing impact is not established.

Reproduction

The following describes the before-and-after behavior I observed. It is not yet a repeatedly verified, deterministic minimal reproduction:

1. Sign in to Codex App with a ChatGPT account and enable OpenCodex's Codex integration.
2. Use the configuration shown under Redacted configuration. Confirm that the old Luna reviewer override is commented out and that the catalog's reviewer override fields are empty/unset.
3. Use Codex for tasks that require automatic approval reviews and inspect the relevant call statistics. Before disabling OpenCodex, the inspected records showed GPT-6.1 Sol / low, totaling 853 calls and 95,481,177 tokens.
4. Disable the OpenCodex integration and restore native Codex direct access. This means restoring direct connectivity, not merely stopping the proxy process while leaving Codex pointed at local port 10100.
5. Continue using Auto-review. The direct-access records show codex-auto-review / low, with 2 calls and 140,189 tokens.

Comparison conditions

• Exact steps used to disable the integration and restore direct access: [Disabled the OpenCodex Codex integration and restored the native Codex configuration. After restoration, the openai_base_url entry was no longer present in config.toml. I then fully restarted Codex App and verified that subsequent requests used the native ChatGPT/Codex connection rather than the local OpenCodex proxy.]
• Whether both paths used the same ChatGPT account and workspace: [Yes. Both paths used the same ChatGPT account and the same workspace. No account or workspace switch was performed between the two observations.]
• Whether Codex App and its bundled runtime were the same versions on both paths: [Yes. Codex App was not updated between the proxied and direct observations. Both observations were made with the same installed Codex App build.]
• Whether the main task model, task, and thread were the same on both paths: [No. The direct-path observation was made in a different/new thread. The purpose of this comparison is only to compare the Auto-review model identity, not identical workload or token usage.]
• Whether Codex was fully quit and reopened after configuration/catalog changes: [Yes. Codex App was fully quit and reopened after disabling the OpenCodex integration and restoring the direct configuration.]
• Proxied observation period and time zone: [2026-10-07 11:45 to 2026-10-07 19:11, UTC+8.]
• Direct observation period and time zone: [2026-10-07 19:15–20:08, UTC+8.]
• Statistics source and filtering criteria: [The statistics were filtered to Auto-review/Guardian requests, then aggregated by model identifier and reasoning effort.]

Version

2.79.0

Operating system

WIN11 24H2

Provider and model

chatpgt 6.1 sol high

Logs or error output

No exception stack trace is attached. The main observation is a difference in model selection or identification:


OpenCodex enabled:
  observed model/display name: GPT-6.1 Sol
  reasoning effort: low
  calls: 853
  total tokens: 95,481,177

OpenCodex disabled; native Codex direct access:
  model: codex-auto-review
  reasoning effort: low
  calls: 2
  total tokens: 140,189


See **Reproduction** for the statistics source, filtering criteria, and observation periods. These aggregates alone do not prove that every Sol request was an approval review or that all corresponding tokens reduced the weekly allowance.

Screenshots and supporting files

Suggested redacted attachments:

1. Statistics screenshots for both connection modes, retaining the observation periods, source, and filters.
2. Evidence showing whether the default reviewer model exists in the effective model catalog, plus the main model's reviewer override field.
3. Corresponding records for one proxied approval review and one direct approval review, retaining the model, effort, Guardian classification, and result status. Do not include full conversations or credentials.
4. Screenshots of the actual OpenCodex and Codex App versions.

Investigation leads — not confirmed root causes

A. Fallback when the default reviewer is missing from the catalog

Codex's select_review_model falls back to the parent model when no override is set and the default reviewer cannot be found in the catalog. It prefers low effort when supported.

This is consistent with the observed GPT-6.1 Sol / low records, but the actual local runtime and effective catalog still need to be checked.

Source reference at a fixed commit; this does not establish that the installed binary uses this exact code:

https://github.com/openai/codex/blob/1fbe15c962cc3d8eabec36d67987c83cfc4eeec9/codex-rs/ext/guardian-reviewer/src/model.rs

Related historical issue: #1225. Existing routing fix: #833.

This report is about preserving the official default reviewer without an override, not requesting another custom reviewer-model feature.

B. Local /v1 URL and Codex backend recognition

In the same Codex source snapshot, supports_codex_backend_routes() checks for the /backend-api/codex suffix on an explicitly configured base URL.

Please verify whether the local /v1 URL used here affects the generation of official reviewer request markers and associated metadata.

Sources:

https://github.com/openai/codex/blob/1fbe15c962cc3d8eabec36d67987c83cfc4eeec9/codex-rs/model-provider-info/src/lib.rs

https://github.com/openai/codex/blob/1fbe15c962cc3d8eabec36d67987c83cfc4eeec9/codex-rs/core/src/client.rs

C. Reviewer marker forwarding

The inspected public v2.80.0 source does not list x-codex-guardian in FORWARD_HEADERS. The configurable forwardClientHeaders allowlist does not include it either.

This is a source-level investigation lead, not evidence from a local capture proving that a header was dropped, and it does not establish the server's billing rules.

https://github.com/lidge-jun/opencodex/blob/v2.80.0/src/adapters/openai-responses/passthrough.ts

https://github.com/lidge-jun/opencodex/blob/v2.80.0/src/lib/provider-client-headers.ts

Questions for maintainers

• For an actual proxied approval review, is the incoming model already Sol when the request reaches OpenCodex, or is it still codex-auto-review?
• Does the catalog actually loaded by the Codex runtime contain the default reviewer model?
• Are genuine Codex-generated reviewer markers and parent-request correlation metadata preserved across both HTTP and WebSocket paths?
• Is this a catalog-selection issue, runtime compatibility issue, request-forwarding issue, or statistics-classification issue?

I am not proposing to work around this by statically marking ordinary requests as Guardian, fabricating reviewer metadata, or disabling safety approvals.

Questions for maintainers

• For an actual proxied approval review, is the incoming model already Sol when the request reaches OpenCodex, or is it still codex-auto-review?
• Does the catalog actually loaded by the Codex runtime contain the default reviewer model?
• Are genuine Codex-generated reviewer markers and parent-request correlation metadata preserved across both HTTP and WebSocket paths?
• Is this a catalog-selection issue, runtime compatibility issue, request-forwarding issue, or statistics-classification issue?

I am not proposing to work around this by statically marking ordinary requests as Guardian, fabricating reviewer metadata, or disabling safety approvals.

Redacted configuration

The following is a snippet from Codex's `config.toml` (**TOML, not JSON**):


approvals_reviewer = "auto_review"
approval_policy = "on-request"
sandbox_mode = "workspace-write"

# auto_review_model = "gpt-6-luna"

openai_base_url = "http://127.0.0.1:10100/v1"


Model catalog:

- The relevant `auto_review_model_override` fields are empty/unset.
- Whether an entry with `slug: "codex-auto-review"` exists: [- Whether an entry with `slug: "codex-auto-review"` exists:
  Yes. The OpenCodex-generated catalog contains a `codex-auto-review` entry.
  It is marked with `visibility: "hide"` and supports low/medium/high/xhigh/max reasoning levels.
  No `auto_review_model_override` is configured for the main model.]
- Effective `model_catalog_json` / profile: [- Effective `model_catalog_json` / profile:
  `model_catalog_json = "C:\Users\<redacted>\.codex\opencodex-catalog.json"`
  No explicit Codex profile was configured; the root/default configuration was used.]

Checks

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