›_ Codex Issues
Codex Issues / #31705

This model is not supported when using X-OpenAI-Internal-Codex-Responses-Lite

Open 💬 3 comments Opened Jul 9, 2026 by luwei1990
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

26.623.141536

What subscription do you have?

plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

This model is not supported when using X-OpenAI-Internal-Codex-Responses-Lite.

What steps can reproduce the bug?

Reproduction:

codex exec -m gpt-5.4 --skip-git-repo-check "Reply with exactly: OK"

Result:

OpenAI Codex v0.143.0
model: gpt-5.4
provider: custom
codex
OK

Then:

codex exec -m gpt-5.5 --skip-git-repo-check "Reply with exactly: OK"

Result:

{
"type": "error",
"error": {
"type": "invalid_request_error",
"code": "unsupported_value",
"message": "This model is not supported when using X-OpenAI-Internal-Codex-Responses-Lite.",
"param": "model"
},
"status": 400
}

What is the expected behavior?

GPT-5.5 should work with a ChatGPT subscription account in Codex, or Codex should not route GPT-5.5 through the Responses-Lite transport if that transport does not support it.

Actual behavior:

GPT-5.5 fails with:

This model is not supported when using X-OpenAI-Internal-Codex-Responses-Lite.

while GPT-5.4 works in the same environment.

This looks like a model routing or model metadata issue for GPT-5.5 on the ChatGPT subscription / OpenAI auth path, not a general network or account issue.

Additional information

_No response_

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

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

  • #31150
  • #30403
  • #30406
  • #30461
  • #30912

Powered by Codex Action

sunflower-zzn · 1 month ago

I can reproduce the same 400 unsupported_value error specifically in the automatic approval reviewer path.

Environment:

  • Codex Desktop: 26.715.72359 (build 5718)
  • Bundled CLI: 0.145.0-alpha.30
  • Platform: macOS
  • Auth mode: ChatGPT
  • Main task model: gpt-5.6-sol

Observed behavior:

  1. The main task runs normally.
  2. An action requiring approval triggers a separate reviewer task using model=codex-auto-review.
  3. The reviewer request fails before producing any tokens:

``
400 unsupported_value
This model is not supported when using X-OpenAI-Internal-Codex-Responses-Lite.
param: model
``

  1. Codex then converts that reviewer infrastructure failure into:

``
This action was rejected due to unacceptable risk.
Reason: Automatic approval review failed: ...
``

This is not a risk-policy denial: the reviewer model call itself fails. In one hour I observed 7 actual tool rejections across 4 task threads with the same signature.

The current model catalog entry for codex-auto-review advertises use_responses_lite: true, while the backend rejects that model on the Lite route. This looks like a model metadata/routing mismatch.

Expected behavior:

  • Do not route codex-auto-review through Responses Lite when unsupported, or retry through the full Responses path.
  • If the reviewer infrastructure fails with a 4xx/model compatibility error, fall back to manual user approval instead of reporting the action as unacceptable risk.

Related auto-review failures: #31255 and #33085.

ss-farm-systems · 1 month ago

Confirmed the Guardian-specific failure on macOS with Codex CLI 0.145.0 and ChatGPT auth.

Observed on 2026-07-23:

  • The installed client's fresh remote catalog returned codex-auto-review as GPT-5.6-Terra with use_responses_lite=true.
  • The bundled catalog and current main both define codex-auto-review with use_responses_lite=false.
  • When an approval reached Guardian, the backend rejected the Lite request with 400 unsupported_value before Guardian produced a policy decision.

I tested a narrow request-time guard on main at 44d76c6a6dd04fa2efc302b906ac8774267a1272:

  • Apply only when the session source is Guardian.
  • Apply only when the effective model slug is exactly the provider's default codex-auto-review.
  • If remote metadata says Lite, clone the request's ModelInfo and set use_responses_lite=false.
  • Leave explicit auto-review model overrides and ordinary Lite sessions unchanged.
  • Use the corrected request metadata consistently for HTTP, WebSocket, prewarm, and compaction. There is no retry, user-review fallback, or auto-approval.

Validation:

  • 3 focused regression tests passed.
  • 32 related Auto-review and Responses-Lite tests passed.
  • just fix -p codex-core passed.
  • codex-cli built successfully.
  • Feeding the installed client's exact bad catalog into the patched binary emitted disabling Responses Lite for the default Guardian approval reviewer, returned a real Guardian declined decision, and completed the turn. There was no unsupported_value or Responses-Lite transport error.

The declined outcome is important: policy remained fail-closed, but Guardian was able to evaluate the request instead of an infrastructure 400 being mislabeled as unacceptable risk.