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

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

• #30406
• #30238
• #30224
• #30403
• #30388

Powered by Codex Action

Directly enter temporary bypass using X-OpenAI-Internally Codex-Responsives-Lite to continue feasible

This is still an issue in 26.715.72359. I can't even downgrade models. The error happens with 5.5. and 5.4.

Same here

same

same, also on "26.715.72359" and tried with many models including 5.4

@chaostheory @dev-2null @cadmusthefounder run this script to change your local file to not use lite models. every time your chatgpt app opens it overwrites this so this locks the file so it cant do that. this will kill your app btw, then you need to restart

replace {home} with your home dir.

pkill -x ChatGPT 2>/dev/null; pkill -x codex 2>/dev/null; pkill -x codex-code-mode-host 2>/dev/null; perl -pi.bak -e 's/"use_responses_lite": true/"use_responses_lite": false/g' {home}/.codex/models_cache.json && chmod 444 {home}/.codex/models_cache.json && jq -r '.models[] | [.slug, (.use_responses_lite|tostring)] | @tsv' {home}/.codex/models_cache.json

models_cache.json is an internal Codex model-capability cache under ~/.codex, not a normal user config file. As a temporary workaround for the July 23, 2026 X-OpenAI-Internal-Codex-Responses-Lite approval bug, you can change every "use_responses_lite": true to false and make the file read-only so Codex does not regenerate it on startup. This can unblock broken approval/review flows, but it also freezes the local model catalog, so future model metadata, rollout flags, and fixes may not update until you unlock the file again.

@0xBison My friend, thank you so much! This method really worked. I was having an issue where my ChatGPT Work couldn’t connect to an open Excel workbook, so I wasn’t able to work with it. Your solution really helped. Thank you so much!

@ZinedinZidan np, but i just tried again and it seems codex resets this periodically. even if you block the file after some time it happens again and it stores the updated config in memory vs the file. is this happening for you guys also?

@0xBison after I messaged you, I ran into the same problem again. Surprisingly, Codex suggested a solution on its own. It told me to switch from auto-approval mode to “Ask for permission,” basically manual mode.

Now, when it asks me for permission itself, it doesn’t trigger that buggy error and works fine with the connected apps. Give it a try — maybe it’ll solve the problem for you too.

@ZinedinZidan i have also discovered the same workaround. I believe this is because I'm working in a directory which has many github repositories in but not sure as i havent tested on other directories yet.

thanks for getting back to me

I hope this gets solved quickly. Do we know if the developers are even aware of this issue?

Codex Sandbox Approval Failure

Issue Summary

When Codex attempts to run lark-cli outside the sandbox, the command is rejected before it reaches Feishu/Lark.

The error is:

Automatic approval review failed:
This model is not supported when using
X-OpenAI-Internal-Codex-Responses-Lite.

As a result, Codex cannot access the Feishu Sheets API or verify the current user identity.

Current Authentication Result

The local user token is present and still valid:

"user": {
  "status": "verify_failed",
  "verified": false,
  "tokenStatus": "valid"
}

The expected successful result is:

"user": {
  "status": "ready",
  "verified": true,
  "tokenStatus": "valid"
}

Root Cause

This is not a Feishu authorization or scope problem.

Two separate restrictions are involved:

1. Commands running inside the sandbox cannot access the configured local proxy at 127.0.0.1:7897.
2. Direct network access without the proxy is also blocked by the sandbox.

Therefore, lark-cli must run outside the sandbox.

However, the current Codex task uses automatic approval:

approvalsReviewer: auto_review

The automatic approval reviewer is incompatible with the current custom model/provider path. It fails with the X-OpenAI-Internal-Codex-Responses-Lite model error before reviewing or executing the command.

The request never reaches Feishu, so restarting Feishu authorization, adding scopes, or logging in again will not solve the issue.

Recommended Solution

Change the approval mode for the current Codex task:

Approve for me / Automatic approval

to:

Ask me / User approval

Keep the permission profile set to:

Workspace

This bypasses the failing automatic reviewer while preserving the sandbox boundary. Codex will then display the sandbox-exit request directly to the user for manual approval.

After changing the setting, retry:

lark-cli auth status --json --verify

The authentication check is successful only when the output contains:

"status": "ready",
"verified": true

Then retry the read-only Sheets request:

lark-cli sheets +workbook-info \
  --as user \
  --spreadsheet-token QsKosKhjxh7SQ4t9Ap6cyjCxnZc

Alternative Fix

The underlying Codex configuration can also be corrected by using a model/provider combination supported by the automatic approval reviewer.

This is a broader configuration change and may affect other tasks. Switching the current task to user approval is the smaller and safer immediate solution.

Important Notes

• Do not reauthorize Feishu unless Feishu returns an actual authentication error such as 401, 403, invalid_token, token_expired, or missing_scopes.
• Do not disable the local proxy as a permanent workaround. Without the proxy, the sandbox cannot resolve the Feishu API domains.
• Do not use an old spreadsheet snapshot after this failure.
• No Feishu or Paipai business data was modified during the failed attempts.