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

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

似乎已经修复了。

好像并没有

still not fixed. Codex version 26.623.41415

still not fixed

model = "gpt-5.5"
model_reasoning_effort = "medium"
model_provider = "chatgpt-http"
I removed these settings in the config.toml, it worked

Mac上的codex也有同样的问题，完全用不了，真糟糕

same issue here, everything with proxied model was down, like headroom or cc-switch.

still not fixed

Edit: seems to work now

still not fixed, regretting upgrading now as it happened as soon as I upgraded.

Edit: appears to be working again now.

the same problem

I’m having the same problem: “This model is not supported when using X-OpenAI-Internal-Codex-Responses-Lite.” The issue still persists even after the update.

me too，It was okay last night

26.623.42026 still not fixed

我的情况是原先折腾过本地模型，把那部分恢复删掉就好了；希望对你们也有帮助 config.toml 这个文件

我的情况是原先折腾过本地模型，把那部分恢复删掉就好了；希望对你们也有帮助 config.toml 这个文件

完全没搞过本地模型，求教

still not fixed

注释掉 config.toml中“model_provider = "openai_http"“这一行之后，就可以使用了，但之前的项目对话记录都没了

切换到5.4，恢复正常

I copied and pasted the error code into codex, and it was able to troubleshoot and fix itself, if that helps anyone else?

还没有解决

still not working

注释掉 config.toml中“model_provider = "openai_http"“这一行之后，就可以使用了，但之前的项目对话记录都没了，可以把这个问题从头到尾告诉codex让他自己修复，目前我已经成功恢复使用

After commenting out this line in config.toml:

model_provider = "openai_http"

Codex started working again, but the previous project conversation history is gone. You can explain the whole issue to Codex from beginning to end and let it fix itself. At this point, I have successfully restored Codex and can use it again.

Mac still not working

用openai_http当provider的原因是默认provider太卡了，而且改成http也是codex自己修复的😂
还是得等修复

刚刚点了更新没修好

把model_provider那几行都注释掉就行，但是我有多个账号，改动之后历史记录要切来切去很麻烦，只能等修复了，刚给官方写了help邮件，希望早点修，多账号要保证本地一致性映射来回切换太麻烦了

好像修复了

I have the same problem

I have the same problem

I have the same problem

$codexDir = Join-Path $env:USERPROFILE ".codex"
$config = Join-Path $codexDir "config.toml"
$backup = Join-Path $codexDir ("config.backup-" + (Get-Date -Format "yyyyMMdd-HHmmss") + ".toml")

New-Item -ItemType Directory -Force -Path $codexDir | Out-Null

if (Test-Path $config) {
Copy-Item $config $backup -Force
Write-Host "已备份原配置到：$backup"
}

@'
model = "gpt-5.5"
model_provider = "openai"
model_reasoning_effort = "high"
'@ | Set-Content -Path $config -Encoding UTF8

Write-Host "Codex 配置已修复。请完全退出 Codex 后重新打开。"
用了这个解决了

Workaround: in model_cache.json: "use_responses_lite": true => false

I have the same problem

I have the same problem

I have the same problem

Workaround: in model_cache.json: "use_responses_lite": true => false

not work.
when start Codex app, the model_cache.json config: "use_responses_lite": false auto changed to true.

I have the same problem

I have the same problem

<img width="753" height="633" alt="Image" src="https://github.com/user-attachments/assets/25c79dfd-2ac6-4e76-92bf-703c61f58d09" />

Solution pointed by @qipenglin make it regeneration-proof

<img alt="图像" width="753" height="633" src="https://private-user-images.githubusercontent.com/12069629/614101227-25c79dfd-2ac6-4e76-92bf-703c61f58d09.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODI1NzYwNzksIm5iZiI6MTc4MjU3NTc3OSwicGF0aCI6Ii8xMjA2OTYyOS82MTQxMDEyMjctMjVjNzlkZmQtMmFjNi00ZTc2LTkyYmYtNzAzYzYxZjU4ZDA5LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA2MjclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwNjI3VDE1NTYxOVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTUzOWI0MDc0ZjA2OWI2NjI2NzY1NTM5MzEyNTZmNjhjMDFjNTg1NDE2ODgzZTc0MGYxODg4Y2JjYzZiNjUyMTgmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.ZGG1FO_YwQEEDiUyceCDutZuqiInrSnLV5pyEGv_90o">

改了以后历史记录没了，还不能设置沙盒...

<img width="1110" height="144" alt="Image" src="https://github.com/user-attachments/assets/f94ce53b-1b34-47e8-b2c0-39baf096e808" />

5.5 Still can't work but gpt 5.4 is ok

I have the same problem really frustrating

I found a workaround.

Disabling CCSwitch → Unified Codex Conversation History fixes the issue immediately. After restarting Codex Desktop, all models work again.

It may be related to the interaction between the latest Codex Desktop update and CCSwitch.

I found a workaround. Disabling CCSwitch → Unified Codex Conversation History fixes the issue immediately. After restarting Codex Desktop, all models work again. It may be related to the interaction between the latest Codex Desktop update and CCSwitch.

Thanks

But I never used ccswitch

But I never used ccswitch

Well... there goes my theory. Looks like CCSwitch is just one way to trigger it, not the root cause.

on macos codex via CLI, running /model and switching to a lower model and lower effort fixed it for me

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.

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

Hope this helps anyone running into the same issue.

<img width="806" height="761" alt="Image" src="https://github.com/user-attachments/assets/533cad13-4c98-4563-a24c-c8a87cedfa97" />
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配置解决了这个问题。 1. 进入Codex→设置→配置。 2. 点击打开config.toml，删除所有内容（留空）。 3. 点击重置并安装 Workspace → 重新安装。 4. 重启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: @.*&gt;
Date: Thu, Jul 2, 2026 13:11 PM
To: @.*&gt;;
Cc: @.****@.**&gt;;
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: @.***&gt;

@MrBear999-ui NONO

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

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

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

> 我通过完全重置Codex配置解决了这个问题。 > > 1. 进入Codex→设置→配置。 > 2. 点击打开config.toml，删除所有内容（留空）。 > 3. 点击重置并安装 Workspace → 重新安装。 > 4. 重启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.