Codex with GPT-5.6-Sol through Azure fails every turn with X-OpenAI-Internal-Codex-Responses-Lite

What version of Codex CLI is running?

v0.144.0

What subscription do you have?

Azure Foundry

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Darwin 24.6.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

cmux

Codex doctor report

What issue are you seeing?

I am attempting to use GPT-5.6-Sol through Azure Foundry. Previous versions like gpt-5.5 work fine, but when I select gpt-5.6-sol, I get the following error for any message I send:

──────────────────────────────────────────────────╮
│ >_ OpenAI Codex (v0.144.0)                       │
│                                                  │
│ model:     gpt-5.6-sol medium   /model to change │
│ directory: ~/stratulus/vibechk                   │
╰──────────────────────────────────────────────────╯

  Tip: New Build faster with the Codex App. Run 'codex app' or visit https://chatgpt.com/codex?app-landing-page=true


› Testing


■ {
  "error": {
    "message": "X-OpenAI-Internal-Codex-Responses-Lite only supports function tools, custom tools, and client-executed tool search.",
    "type": "invalid_request_error",
    "param": "tools",
    "code": "unsupported_value"
  }
}

What steps can reproduce the bug?

Connect Codex to Azure using the instructions here:
https://learn.chatgpt.com/docs/config-file/config-advanced#azure-provider-and-per-provider-tuning
Launch codex
Switch models to gpt-5.6-sol
Type any text, like "testing"
See the error

What is the expected behavior?

No response

Additional information

No response

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

This model is not supported when using X-OpenAI-Internal-Codex-Responses-Lite #31705
gpt-5.5 on ChatGPT account is routed to Responses-Lite and fails with unsupported_value #31150
Codex Desktop wrongly routes GPT-5.5 to Responses Lite, causing avoidable failures and wasted tokens #31717
Bug: "Model not supported when using X-OpenAI-Internal-Codex-Responses-Lite" error with latest models #30461

Powered by Codex Action

By the way, it looks like use_responses_lite is set per-model from the model catalog metadata. It becomes true when the model’s JSON from OpenAI’s /models endpoint (or the bundled models.json ) contains "use_responses_lite": true .

In the current bundled catalog ( codex-rs/models-manager/models.json ), that’s true for:
• gpt-5.6-sol
• gpt-5.6-terra
• gpt-5.6-luna

It’s false for older models like gpt-5.5 , gpt-5.4 , gpt-5.2 , etc.

So the models.json is explicitly setting use_responses_lite for the gpt-5.6 models but it does not look supported on the other end.

Possible workaround tested with Codex 0.144.0, Azure Foundry, and gpt-5.6-sol:

Override the model catalog so gpt-5.6-sol has "use_responses_lite": false.
Set features.multi_agent_v2.tool_namespace="agents".

Disabling Responses Lite alone produced a second error because collaboration is reserved for encrypted tool use. We have gotten this to work as a temporary workaround, but we are still testing fully.

I can reproduce this on Linux/WSL with Codex CLI 0.144.0, Azure OpenAI / Foundry, deployment gpt-5.6-sol.

The important detail seems to be that the Azure deployment itself works fine. Direct Azure Responses API calls succeed:

POST https://.cognitiveservices.azure.com/openai/responses?api-version=2025-04-01-preview
api-key:
Content-Type: application/json
Payload:

{
"model": "gpt-5.6-sol",
"input": "Reply exactly: OK",
"max_output_tokens": 64,
"store": false,
"reasoning": {
"effort": "high",
"summary": "auto"
}
}
This returns OK.

I also tested Azure reasoning efforts directly:

none works
low works
medium works
high works
xhigh works
max works
ultra rejected by Azure
So this does not look like a bad Azure deployment/key/endpoint issue.

I put a localhost proxy between Codex and Azure to inspect the request. Codex sends a Responses payload containing an additional_tools developer item. In
my request, Codex included:

exec
wait
request_user_input
collaboration
The collaboration entry is a namespace tool:

{
"type": "namespace",
"name": "collaboration",
"description": "Tools for spawning and managing sub-agents."
}
When I strip Codex-only headers and forward the request to the Azure preview endpoint, Azure rejects this with a more specific error:

{
"error": {
"message": "Invalid Value: 'tools'. Namespace 'collaboration' is reserved for encrypted tool use by this model.",
"type": "invalid_request_error",
"param": "tools",
"code": null
}
}
If I remove only that collaboration namespace tool from the additional_tools item, Codex works successfully against Azure gpt-5.6-sol, including normal
shell tool use.

Example successful workaround behavior after stripping collaboration:

codex exec "Use shell to run pwd, then reply with only the resulting path."
Codex successfully calls shell and returns the path.

So I think there are two overlapping issues:

gpt-5.6-* models are marked with use_responses_lite = true, causing Codex to send/request Responses Lite behavior that Azure rejects:
X-OpenAI-Internal-Codex-Responses-Lite only supports function tools, custom tools, and client-executed tool search.
Even after stripping internal headers, Codex sends the collaboration namespace tool, which Azure gpt-5.6-sol currently rejects:
Namespace 'collaboration' is reserved for encrypted tool use by this model.
It would help if Codex had either:

Azure/custom-provider override to disable use_responses_lite,
config flag to disable the collaboration namespace / multi-agent additional tools,
provider capability detection for Azure Responses,
or model catalog correction for gpt-5.6-sol, gpt-5.6-terra, and gpt-5.6-luna.
For now my workaround is a local proxy that forwards to:

/openai/responses?api-version=2025-04-01-preview
and removes the collaboration namespace from additional_tools. With that, normal single-agent Codex works on Azure gpt-5.6-sol, including
reasoning.effort = "max", but native Codex subagents/collaboration cannot work because the rejected namespace has to be stripped.

Rolling back to 0.142.5 cli version does temporarily allow 5.6 series models to bypass this error, but waiting for the fix that'll help with the new codex app as well as codex plugins.

Reproduction notes and proposed fix path

I took a pass at reducing this to an actionable code path before suggesting a fix.

Breakdown:

Root cause: codex-rs/core/src/client.rs:829
Impact: calibrated priority score 45.37771617

Proposed approach:

Keep the patch scoped to the code path around codex-rs/core/src/client.rs:829, so the behavior changes where the regression is introduced rather than broadening the surface area.
Validation plan: ran just test -p codex-core responses_lite_model_uses_standard_responses_for_custom_provider responses_websocket_sends_responses_lite_metadata_per_request → pass
Prepared fork branch: codex-saga/fix-codex-triage_dup_openai_codex_31870 · compare vs upstream
I will not open an unsolicited PR; if this direction matches maintainer expectations, I can open the prepared branch for review.

Precedent: #29189 Codex Desktop 26.616.41845 node_repl fails: codex/sandbox-state-meta missing sandboxPolicy

How I shaped this comment from prior successful threads:

Nearest successful examples considered: 3.
The shared pattern was to show the repro/root-cause evidence first, state the smallest viable fix, defer to maintainers on direction, and disclose AI assistance.

This analysis was prepared with AI assistance.

trace

Happens on codex 0.144.1 too. Same error message

My Workaround is to modify these two configurations, I hope this helps everyone. This seems to be new additions in the 5.6 model.

 "models": [
  {
   "slug": "gpt-5.6-sol",
   ...
   "use_responses_lite": false,
   "multi_agent_version": null
  }

Aligning with the GPT-5.5 configuration (both fields are empty in GPT-5.5). This corresponds exactly to the conclusion of issue #26753: when v2 multi-agent tools include encrypted parameter schemas and the model/backend is not configured with encryption tool support, the entire request gets rejected with a 400 error

@LucasXXYY

@LucasXXYY
This workaround worked for me, but caching is not working at all. 100% of the input tokens are not cached, which makes it extremely expensive.

not sure but i thinked they fixed it with latest, still not with ultra mode i'm getting :
Invalid Value: 'tools.namespace'. User-defined namespace 'image_gen' collides with an existing tool namespace.

It looks like Azure has resolved this issue, as I haven't encountered the same problem again today(2026-07-13 09:56 UTC+8).

Can anyone verify if the prompt caching issue is also gone?

It seems to be resolved.

Works now. Thanks

It appears that the Azure-specific behavior discussed in this issue has now been substantially addressed upstream. I do not want to present the project below as a fix for this issue, or encourage anyone to use a local workaround when the upstream update resolves their case.

Separately, I maintain Codex Provider Compatibility, an unofficial and reversible diagnostic tool for a narrower situation that may still affect users of other third-party OpenAI-compatible providers.

It only considers gpt-5.6-sol, gpt-5.6-terra, and gpt-5.6-luna when text responses work but Codex tool calls, such as shell, function, or MCP calls, disappear or are described only in text. The tool starts with a read-only doctor check and refuses to proceed unless it can establish that the local state is applicable and safe. When appropriate, it can create a temporary local catalog override that uses the standard Responses tool shape, and it supports rollback.

This is not an official fix, does not replace upstream updates, and is not suitable for every provider or tool-call failure. It does not modify provider settings, read credentials or auth.json, send requests to the configured provider, or automatically choose between conflicting Codex versions.

I am sharing it only as a possible diagnostic and temporary mitigation for users whose issue remains after applying the relevant upstream fixes. If anyone tests it in a different third-party-provider environment, a redacted doctor result, Codex version, provider category, and observed tool-call behavior would be useful. Please do not post endpoints, credentials, raw requests, usernames, or private paths.

No, it's not resolved, if you set supports_websockets = false then everything is fine, but if websockets turned on, you still have this issue:

{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "code": "unsupported_value",
    "message": "X-OpenAI-Internal-Codex-Responses-Lite only supports function tools, custom tools, and client-executed
tool search.",
    "param": "tools"
  },
  "status": 400
}

Would changing the Responses Lite request format to the standard Response format resolve this issue? Perhaps Azure overlooked the supports_websockets = false setting during the adaptation process.

I'm not sure what your specific configuration is. I've fully switched to the 5.6 model, and here's my model-catalog.json and config.toml. Hope it helps!

{
  "models": [
    {
      "slug": "gpt-5.6-sol",
      ......
      "supports_search_tool": true,
      "use_responses_lite": true,
      "tool_mode": "code_mode_only",
      "multi_agent_version": "v2"
    },
    {
      "slug": "gpt-5.6-terra",
      ......
      "supports_search_tool": true,
      "use_responses_lite": true,
      "tool_mode": "code_mode_only",
      "multi_agent_version": "v2"
    }
  ]
}

config.toml

model = "gpt-5.6-terra"
model_provider = 'azure'
model_catalog_json = "model-catalog.json"
......
[features]
memories = true
js_repl = false
multi_agent = true

[model_providers]
[model_providers.azure]
......
requires_openai_auth = true

Try Codex Provider Compatibility ; You can switch to GPT5.5 and let your Codex to use it or run the script.

Yes, this configuration doesn't work with gpt-5.5, which is why I switched to 5.6.
But you can try updating the config.toml, setting requires_openai_auth = false. Hope that helps!

What ?

Sorry, I misunderstood.

Hope my tools are helpful. If you test it in a different third-party-provider environment, a redacted doctor result, Codex version, provider category, and observed tool-call behavior would be useful.

For Azure Foundry users where gpt-5.6-sol fails every turn: the client marks gpt-5.6 models with use_responses_lite=true in its model catalog and sends the internal X-OpenAI-Internal-Codex-Responses-Lite header with Responses-Lite tool-call encoding, which Azure rejects with the unsupported-tools error.

Method:

In config.toml for the Azure provider, pin a model that does not use Responses-Lite, e.g. model = "gpt-5.5" (gpt-5.4 and gpt-5.2 also work).
Restart codex and re-test with the same Azure endpoint; the Responses-Lite header no longer appears in the request.
Once Azure supports Responses-Lite, switch back to gpt-5.6-sol.

Evidence: verified against the model catalog on main (codex-rs/models-manager/models.json): gpt-5.6-sol/terra/luna all set use_responses_lite=true, while gpt-5.5/5.4/5.2 set it false. The Azure error in this thread matches the rejection of that header for the tool-call path.

Independent community workaround; not an official OpenAI fix.

Navigation Menu

Repository navigation

Codex with GPT-5.6-Sol through Azure fails every turn with X-OpenAI-Internal-Codex-Responses-Lite #31870

What version of Codex CLI is running?

What subscription do you have?

Which model were you using?

What platform is your computer?

What terminal emulator and version are you using (if applicable)?

Codex doctor report

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Reproduction notes and proposed fix path

26 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Codex with GPT-5.6-Sol through Azure fails every turn with X-OpenAI-Internal-Codex-Responses-Lite #31870

Description

What version of Codex CLI is running?

What subscription do you have?

Which model were you using?

What platform is your computer?

What terminal emulator and version are you using (if applicable)?

Codex doctor report

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Jul 9, 2026

wikcheng commented on Jul 9, 2026

bluerssen commented on Jul 9, 2026

Soorma718 commented on Jul 9, 2026

dennyatudp commented on Jul 9, 2026

ctkm-aelf commented on Jul 10, 2026

Reproduction notes and proposed fix path

yidasanqian commented on Jul 10, 2026

JussiSpogen commented on Jul 10, 2026

LucasXXYY commented on Jul 10, 2026

lstkz commented on Jul 10, 2026

26 remaining items

Rafik-Belkadi-Reccap commented on Jul 12, 2026

kenny7869 commented on Jul 13, 2026

onyedikachi23 commented on Jul 13, 2026

LucasXXYY commented on Jul 13, 2026

onyedikachi23 commented on Jul 13, 2026

Hyacehila commented on Jul 14, 2026

sdcb commented on Jul 15, 2026

Hyacehila commented on Jul 15, 2026

LucasXXYY commented on Jul 15, 2026

Hyacehila commented on Jul 15, 2026

LucasXXYY commented on Jul 15, 2026

Hyacehila commented on Jul 15, 2026

LucasXXYY commented on Jul 15, 2026

Hyacehila commented on Jul 15, 2026

naipi11 commented on Aug 18, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions