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

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

26.623.31921

What subscription do you have?

plus

What platform is your computer?

win11

What issue are you seeing?

The API returns this error when using X-OpenAI-Internal-Codex-Responses-Lite:

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

We are using gpt-5.5-high and gpt-5.5-xhigh. Please help confirm whether these models are supported with this header.

What steps can reproduce the bug?

After updating to the latest version, the issue occurs when starting a new conversation.

Steps to reproduce:

Set model_provider = "openai_http".
Start a new conversation.
Use gpt-5.5-high or gpt-5.5-xhigh.
Send any message.
The request fails with the error:

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

What is the expected behavior?

No response

Additional information

No response

Confirming this is not limited to custom provider aliases like gpt-5.5-high / gpt-5.5-xhigh.

I reproduced the same failure on stock Codex Desktop for Windows by selecting the built-in gpt-5.5 model from the model picker in a normal thread.

What I observed:

Fully restarted the app and opened a new window.
Started/continued a normal desktop thread.
Switched the model to gpt-5.5.
Sent a prompt.
The request failed immediately with:
This model is not supported when using X-OpenAI-Internal-Codex-Responses-Lite.

Additional evidence from local session transcripts:

Failing thread/session id: 019f03a2-5384-7cc2-8f6a-ffaafb93a993
In the failing transcript, the turn context records model: gpt-5.5, but the task completes with last_agent_message: null.
More failing gpt-5.5 attempts around 2026-06-26 19:27-19:28 local time showed the same pattern.
In the same workspace on the same machine, switching back to gpt-5.4 succeeds immediately.

So this seems broader than only openai_http + custom gpt-5.5-high / gpt-5.5-xhigh names. It also affects the standard Windows desktop model picker path for gpt-5.5.

I filed this separately as #30238 at first because the surface looked different, but after comparing them I am closing that report as a duplicate of this issue and consolidating the desktop-specific evidence here.

Thanks for the update.

Could you please provide an estimated time for when gpt-5.5 will be available again in Codex Desktop? I urgently need to use it, but it currently fails with:

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

Is there any temporary workaround, such as disabling the Lite route or forcing a compatible backend route?

我也遇到了同样问题

Thanks for looking into this. Could a maintainer please clarify two things for the stock Windows Codex Desktop case? 1. Is there any rough ETA for when built-in `gpt-5.5` support will be available again? 2. Is there any supported temporary workaround, or is the only recommended fallback to use `gpt-5.4` until this is fixed? For context, this is reproducible for me on the standard Windows desktop model picker path as well, not only with custom `openai_http` model aliases. After restarting the app and opening a new window, selecting built-in `gpt-5.5` still fails with: `This model is not supported when using X-OpenAI-Internal-Codex-Responses-Lite.`

why the fuck i updated bruh

I encountered the same issue. The problematic Codex version was codex-cli 0.142.2, but when I reopened Codex, it prompted me to upgrade to version 0.142.3. The funny thing is that even after I upgraded, it still prompted me to upgrade—meaning that version 0.142.3 was still using the 0.142.2 version number. However, at least it no longer reports the error “This model is not supported when using X-OpenAI-Internal-Codex-Responses-Lite.”

Confirming the same issue on the stock Windows Codex Desktop path.

Environment:

Subscription: ChatGPT Plus (active)
Platform: Windows
Codex Desktop app version reported in local config: 26.616.41845
Built-in model selected from the model picker: gpt-5.5

Behavior:

gpt-5.5 fails immediately with:
This model is not supported when using X-OpenAI-Internal-Codex-Responses-Lite.
gpt-5.4 works normally in the same app, account, workspace, and network.
Updating and restarting Codex did not fix it.
The local config.toml does not contain model_provider, OPENAI_BASE_URL, wire_api, or a custom OpenAI provider configuration.

This therefore appears to affect the standard official ChatGPT/Codex route as well, not only openai_http or custom model aliases.

Additional diagnostic information for the stock Windows Codex Desktop reproduction reported above:

Codex in-app feedback was submitted successfully.
Feedback ID: 019f067b-4bc7-7093-b5e7-e3ba2d15bf50

This feedback upload should contain the failing session diagnostics for the built-in gpt-5.5 model while gpt-5.4 continues to work normally.

DAMN G ！I just spent $20 on it yestoday, please fix it as soon as possible .

me too

It seems fixed

Previously, to solve the instability issue of WebSockets:
⚠ Falling back from WebSockets to HTTPS transport. request timed out.
I used the following configuration:

model_provider = "openai_http"
model = "gpt-5.5"
model_reasoning_effort = "high"
disable_response_storage = true
network_access = "enabled"
windows_wsl_setup_acknowledged = true
[model_providers.openai_http]
name = "OpenAI HTTP only"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false

It will appear
This model is not supported when using X-OpenAI-Internal-Codex-Responses-Lite.
Switching back to the official default configuration allows normal use of GPT-5.5.

model_provider = "openai"
model = "gpt-5.5"
model_reasoning_effort = "high"
disable_response_storage = true
network_access = "enabled"
windows_wsl_setup_acknowledged = true

I fixed this issue by completely resetting the Codex configuration.

Go to Codex → Settings → Configuration.
Click Open config.toml and delete all its contents (leave it empty).
Click Reset and install Workspace → Reinstall.
Restart Codex.

Hope this helps anyone running into the same issue.

this is the best solution

Emptying content of config.toml sufficed for me. (WSL codex)

Just set use_responses_lite to false in ~/.codex/models_cache.json.
Restart codex.

我通过完全重置Codex配置解决了这个问题。

进入Codex→设置→配置。

点击打开config.toml，删除所有内容（留空）。

点击重置并安装 Workspace → 重新安装。

重启Codex。

希望这能帮到遇到同样问题的人。

有效

I had this issue too, I had just installed headroom. I've removed all headroom config from my config.toml and launched Codex without the headroom wrapper. Then it started working again

重新安装，需不需要重新用手机验证。谢谢

…

---Original--- From: ***@***.***> Date: Thu, Jul 2, 2026 13:11 PM To: ***@***.***>; Cc: ***@***.******@***.***>; Subject: Re: [openai/codex] This model is not supported when using X-OpenAI-Internal-Codex-Responses-Lite. (Issue #30224) wzyhddy left a comment (openai/codex#30224) 我通过完全重置Codex配置解决了这个问题。进入Codex→设置→配置。点击打开config.toml，删除所有内容（留空）。点击重置并安装 Workspace → 重新安装。重启Codex。希望这能帮到遇到同样问题的人。有效 — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

@MrBear999-ui

@MrBear999-ui NONO

codex怎么bug越更新越多了...gpt自己写自己的代码吗

如果你用proxy的话，其实只要加个header rule把这个header移除就可以：
x-openai-internal-codex-responses-lite: true

不然自己写个简单的proxy也可以

我通过完全重置Codex配置解决了这个问题。

进入Codex→设置→配置。

点击打开config.toml，删除所有内容（留空）。

点击重置并安装 Workspace → 重新安装。

重启Codex。

希望这能帮到遇到同样问题的人。

有效

welldone!

A related tool, but with a different scope: Codex Provider Compatibility.

It is not a fix for the gpt-5.5-high / gpt-5.5-xhigh case reported in this issue, and it should not replace the upstream fix or the configuration troubleshooting discussed here. It only targets gpt-5.6-sol, gpt-5.6-terra, and gpt-5.6-luna used through third-party OpenAI-compatible providers, where text responses work but Codex tool calls disappear because of the Responses Lite request shape.

The tool begins with a read-only doctor check and only offers a reversible local workaround when the case is confirmed as applicable and safe. Sharing it here in case someone reaches this issue with that newer-model variant of the problem.

It is encouraging that the Azure-specific behavior reported here now appears to be resolved upstream. For Azure users, I would treat the upstream update as the preferred solution rather than rely on a local workaround.

For users of other third-party OpenAI-compatible providers, I maintain Codex Provider Compatibility, an unofficial diagnostic tool for the narrower case where gpt-5.6-sol, gpt-5.6-terra, or gpt-5.6-luna can return text but tool calls fail or disappear because of the Responses Lite request shape. It does not claim to solve every collaboration, multi-agent, or provider-specific failure described in this thread.

The tool starts with a read-only doctor check and only creates a reversible local catalog override when the local state is confirmed as applicable and safe. It does not read credentials, change provider settings, or send requests to the configured provider. I am sharing it as a possible diagnostic aid for users whose third-party-provider case remains after the relevant upstream fixes.

Navigation Menu

Repository navigation

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

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

46 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

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

MrBear999-ui commented on Jun 26, 2026

linlom025 commented on Jun 26, 2026

xiangxinyanrfmy-spec commented on Jun 26, 2026

MrBear999-ui commented on Jun 26, 2026

riprsa commented on Jun 26, 2026

inbjo commented on Jun 26, 2026

laogongcy-del commented on Jun 27, 2026

laogongcy-del commented on Jun 27, 2026

elecDancing commented on Jun 27, 2026

justkids2018 commented on Jun 27, 2026

wy4ward commented on Jun 27, 2026

46 remaining items

Fucha94 commented on Jun 30, 2026

luckybear101 commented on Jun 30, 2026

Epic0522 commented on Jun 30, 2026

AhmedAkbarali commented on Jun 30, 2026

notnotsamuel commented on Jun 30, 2026

wzyhddy commented on Jul 2, 2026

SolveSoul commented on Jul 2, 2026

MrBear999-ui commented on Jul 2, 2026

horacecar commented on Jul 2, 2026

amospade commented on Jul 3, 2026

harmonypiano commented on Jul 3, 2026

tuotuozhang commented on Jul 5, 2026

Hyacehila commented on Jul 14, 2026

Hyacehila commented on Jul 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions