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

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

• #31705
• #31150
• #31717
• #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:

1. Override the model catalog so gpt-5.6-sol has "use_responses_lite": false.
2. 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://<resource>.cognitiveservices.azure.com/openai/responses?api-version=2025-04-01-preview
api-key: <redacted>
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.

<!-- fkst:codex-saga:engage:codex-triage:dup:openai/codex#31870 -->

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.

``` Json
"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 https://github.com/openai/codex/issues/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
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.

@LucasXXYY
The workaround works for me, too. Thanks! (Codex 0.144.1 & Azure Foundry deploy)

I have the same issue, with Codex CLI 0.144.1 on Windows, and this workaround works:

• Create a custom models.azure.json file in the codex folder, switching off the responses lite and forcing the agent version to v1 (for some reason the models.json didn't exist in my folder)

$json = codex debug models | ConvertFrom-Json
$model = $json.models | Where-Object { $_.slug -eq "gpt-5.6-sol" }
$model.use_responses_lite = $false
$model.multi_agent_version = "v1"
$json | ConvertTo-Json -Depth 100 | Set-Content "$HOME\.codex\models.azure.json"

• Add these in config.toml:

model_catalog_json = '\\?\C:\Users\YOUR_USERNAME\.codex\models.azure.json'
[features]
multi_agent = true
multi_agent_v2 = false

@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.

@lstkz I tried it out. With the same configuration, I tested it using the gpt-5.5 and the input cache worked fine, but it didn't work with the gpt-5.6-*. It's quite strange. Do you have any better suggestions?
We can keep an eye on this post: https://learn.microsoft.com/en-us/answers/questions/5942997/gpt-5-6-implicit-prompt-caching-and-explicit-promp

using the same method above, I created the json file with this information in ubuntu and it worked!

{
"models": [
{
"name": "GPT 5.6 Sol",
"display_name": "GPT 5.6 Sol",
"slug": "gpt-5.6-sol",
"use_responses_lite": false,
"multi_agent_version": "v1",
"supported_reasoning_levels": [],
"shell_type": "default",
"api_type": "azure",
"api_version": "2024-02-01",
"endpoint": "https://localhost",
"max_tokens": 4096,
"visibility": "list",
"supported_in_api": true,
"priority": 1,
"base_instructions": "",
"supports_reasoning_summaries": true,
"support_verbosity": true,
"truncation_policy": {
"mode": "tokens",
"limit": 4096
},
"supports_parallel_tool_calls": true,
"experimental_supported_tools": []
}
]
}

I updated the file to include ALL models as I figured out that the last version only used 5.6 Sol

cat << 'EOF' > "$HOME/.codex/ models.azure.json"
{
"models": [
{
"name": "GPT 5.6 Sol",
"display_name": "GPT 5.6 Sol",
"slug": "gpt-5.6-sol",
"use_responses_lite": false,
"multi_agent_version": "v1",
"supported_reasoning_levels": [],
"shell_type": "default",
"api_type": "azure",
"api_version": "2024-02-01",
"endpoint": "https://localhost",
"max_tokens": 4096,
"visibility": "list",
"supported_in_api": true,
"priority": 1,
"base_instructions": "",
"supports_reasoning_summaries": true,
"support_verbosity": true,
"truncation_policy": {
"mode": "tokens",
"limit": 4096
},
"supports_parallel_tool_calls": true,
"experimental_supported_tools": []
},
{
"name": "GPT 5.6 Terra",
"display_name": "GPT 5.6 Terra",
"slug": "gpt-5.6-terra",
"use_responses_lite": false,
"multi_agent_version": "v1",
"supported_reasoning_levels": [],
"shell_type": "default",
"api_type": "azure",
"api_version": "2024-02-01",
"endpoint": "https://localhost",
"max_tokens": 4096,
"visibility": "list",
"supported_in_api": true,
"priority": 2,
"base_instructions": "",
"supports_reasoning_summaries": true,
"support_verbosity": true,
"truncation_policy": {
"mode": "tokens",
"limit": 4096
},
"supports_parallel_tool_calls": true,
"experimental_supported_tools": []
},
{
"name": "GPT 5.6 Luna",
"display_name": "GPT 5.6 Luna",
"slug": "gpt-5.6-luna",
"use_responses_lite": false,
"multi_agent_version": "v1",
"supported_reasoning_levels": [],
"shell_type": "default",
"api_type": "azure",
"api_version": "2024-02-01",
"endpoint": "https://localhost",
"max_tokens": 4096,
"visibility": "list",
"supported_in_api": true,
"priority": 3,
"base_instructions": "",
"supports_reasoning_summaries": false,
"support_verbosity": true,
"truncation_policy": {
"mode": "tokens",
"limit": 4096
},
"supports_parallel_tool_calls": true,
"experimental_supported_tools": []
},
{
"name": "GPT 5.5",
"display_name": "GPT 5.5",
"slug": "gpt-5.5",
"use_responses_lite": false,
"multi_agent_version": "v1",
"supported_reasoning_levels": [],
"shell_type": "default",
"api_type": "azure",
"api_version": "2024-02-01",
"endpoint": "https://localhost",
"max_tokens": 4096,
"visibility": "list",
"supported_in_api": true,
"priority": 4,
"base_instructions": "",
"supports_reasoning_summaries": true,
"support_verbosity": true,
"truncation_policy": {
"mode": "tokens",
"limit": 4096
},
"supports_parallel_tool_calls": true,
"experimental_supported_tools": []
},
{
"name": "GPT 5.4",
"display_name": "GPT 5.4",
"slug": "gpt-5.4",
"use_responses_lite": false,
"multi_agent_version": "v1",
"supported_reasoning_levels": [],
"shell_type": "default",
"api_type": "azure",
"api_version": "2024-02-01",
"endpoint": "https://localhost",
"max_tokens": 4096,
"visibility": "list",
"supported_in_api": true,
"priority": 5,
"base_instructions": "",
"supports_reasoning_summaries": true,
"support_verbosity": true,
"truncation_policy": {
"mode": "tokens",
"limit": 4096
},
"supports_parallel_tool_calls": true,
"experimental_supported_tools": []
},
{
"name": "GPT-4o",
"display_name": "GPT-4o",
"slug": "gpt-4o",
"use_responses_lite": false,
"multi_agent_version": "v1",
"supported_reasoning_levels": [],
"shell_type": "default",
"api_type": "azure",
"api_version": "2024-02-01",
"endpoint": "https://localhost",
"max_tokens": 4096,
"visibility": "list",
"supported_in_api": true,
"priority": 6,
"base_instructions": "",
"supports_reasoning_summaries": true,
"support_verbosity": true,
"truncation_policy": {
"mode": "tokens",
"limit": 4096
},
"supports_parallel_tool_calls": true,
"experimental_supported_tools": []
},
{
"name": "o1-preview",
"display_name": "o1-preview",
"slug": "o1-preview",
"use_responses_lite": false,
"multi_agent_version": "v1",
"supported_reasoning_levels": [
{ "effort": "high", "description": "" }
],
"shell_type": "default",
"api_type": "azure",
"api_version": "2024-02-01",
"endpoint": "https://localhost",
"max_tokens": 8192,
"visibility": "list",
"supported_in_api": true,
"priority": 7,
"base_instructions": "",
"supports_reasoning_summaries": true,
"support_verbosity": true,
"truncation_policy": {
"mode": "tokens",
"limit": 8192
},
"supports_parallel_tool_calls": false,
"experimental_supported_tools": []
},
{
"name": "o1-mini",
"display_name": "o1-mini",
"slug": "o1-mini",
"use_responses_lite": false,
"multi_agent_version": "v1",
"supported_reasoning_levels": [
{ "effort": "high", "description": "" }
],
"shell_type": "default",
"api_type": "azure",
"api_version": "2024-02-01",
"endpoint": "https://localhost",
"max_tokens": 8192,
"visibility": "list",
"supported_in_api": true,
"priority": 8,
"base_instructions": "",
"supports_reasoning_summaries": true,
"support_verbosity": true,
"truncation_policy": {
"mode": "tokens",
"limit": 8192
},
"supports_parallel_tool_calls": false,
"experimental_supported_tools": []
}
]
}
EOF

Double-write sync to handle the spaced directory name quirk

cp "$HOME/.codex/ models.azure.json" "$HOME/.codex/models.azure.json"

I used this gpt-5.6-sol-xhigh to make a one-liner fix. Use at your own discretion:

python3 -c 'import json,os,re,shutil,subprocess,tempfile; from pathlib import Path; d=Path.home()/".codex"; d.mkdir(parents=True,exist_ok=True); exe=shutil.which("codex") or (_ for _ in ()).throw(SystemExit("codex not found in PATH")); td=tempfile.TemporaryDirectory(); env=os.environ.copy(); env["CODEX_HOME"]=td.name; data=json.loads(subprocess.check_output([exe,"debug","models"],env=env,text=True)); td.cleanup(); model=next((x for x in data.get("models",[]) if x.get("slug")=="gpt-5.6-sol"),None); model is not None or (_ for _ in ()).throw(SystemExit("gpt-5.6-sol not found in Codex model catalog")); model["use_responses_lite"]=False; model["multi_agent_version"]="v1"; catalog=d/"models.azure.json"; tmp=d/"models.azure.json.tmp"; tmp.write_text(json.dumps(data,indent=2)+"\n"); os.replace(tmp,catalog); cfg=d/"config.toml"; old=cfg.read_text() if cfg.exists() else ""; cfg.exists() and shutil.copy2(cfg,str(cfg)+".bak"); first=re.search(r"(?m)^[ \t]*\[",old); head=old[:first.start()] if first else old; tail=old[first.start():] if first else ""; head=re.sub(r"(?m)^[ \t]*(?:model|model_catalog_json)[ \t]*=.*(?:\n|$)","",head); text="model = \"gpt-5.6-sol\"\nmodel_catalog_json = "+json.dumps(str(catalog))+"\n"+head+tail; text+="" if text.endswith("\n") else "\n"; settings="multi_agent = true\nmulti_agent_v2 = false\n"; section=re.compile(r"(?ms)^([ \t]*\[features\][ \t]*(?:#.*)?\n)(.*?)(?=^[ \t]*\[|\Z)"); text=section.sub(lambda m:m.group(1)+settings+re.sub(r"(?m)^[ \t]*multi_agent(?:_v2)?[ \t]*=.*(?:\n|$)","",m.group(2)),text,count=1) if section.search(text) else text+"\n[features]\n"+settings; ctmp=d/"config.toml.tmp"; ctmp.write_text(text); os.replace(ctmp,cfg); print("Codex Azure workaround installed; fully restart Codex/VS Code and start a new conversation.")'

I independently reproduced this on macOS with Codex 0.144.0-alpha.4, Microsoft Foundry, and a gpt-5.6-sol deployment. I traced the request far enough to rule out the usual configuration/authentication causes.

Confirmed working

• Microsoft Foundry authentication and API key
• Foundry resource endpoint and deployment name
• Required environment variables
• Codex provider/config selection
• A clean CODEX_HOME test, eliminating stale local state
• Codex correctly selects the Azure/Foundry provider and gpt-5.6-sol deployment
• The request reaches the Foundry /openai/v1/responses route

GPT-5.5 works through the same provider setup, so this is specific to the GPT-5.6 request/tool path rather than general Foundry connectivity.

Request difference that triggers the failure

Codex injects an additional_tools bundle containing:

• custom tool: exec
• function tool: wait
• function tool: request_user_input
• namespace tool: collaboration

The GPT-5.6 Sol Codex-lite endpoint rejects that request with:

X-OpenAI-Internal-Codex-Responses-Lite only supports function tools, custom tools, and client-executed tool search.

The key incompatibility is the type: "namespace", name: "collaboration" entry. The endpoint accepts the other documented tool categories but not the namespace tool that full Codex agent mode adds.

This lines up with the additional proxy-level findings already posted above: when Responses Lite behavior is bypassed, Foundry gives the more specific error that the collaboration namespace is reserved for encrypted tool use. Removing only that namespace allows normal single-agent shell/tool execution, but necessarily disables native Codex subagent/collaboration behavior.

Likely fix surface

One or more of these appears necessary:

1. Provider capability detection so Azure/Foundry does not receive unsupported Codex-only namespace tools.
2. A custom-provider override for use_responses_lite.
3. A supported config flag to suppress the collaboration namespace / multi-agent v2 tools.
4. Corrected GPT-5.6 Sol/Terra/Luna model-catalog metadata for Azure/Foundry deployments.
5. A documented full-Codex-compatible Foundry deployment/API version/SKU, if one exists.

Until then, GPT-5.6 Sol on Foundry appears usable through thinner Responses API clients or a single-agent workaround, but not full Codex CLI/VS Code agent mode with the collaboration namespace enabled.

Original investigation/thread: https://x.com/BradGroux/status/2075337928948023343

The fix uses both config.toml and a patched model catalog JSON.

In ~/.codex/config.toml, add:

model_reasoning_effort = "max" 
model_catalog_json = "/Users/username/.codex/model-catalogs/azure-gpt56-0.144.1.json"

Note that ultra effort for foundry models not supported yet.

The following settings are not added to config.toml:

"use_responses_lite": false,
"multi_agent_version": null

They are changed inside:

~/.codex/model-catalogs/azure-gpt56-0.144.1.json

Within the gpt-5.6-sol model entry (do similarly for remaining 5.6 family as well if you use them):

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

config.toml simply points Codex CLI to this patched model catalog. Use an absolute path for model_catalog_json.

The fix uses both config.toml and a patched model catalog JSON. In ~/.codex/config.toml, add: model_reasoning_effort = "max" model_catalog_json = "/Users/username/.codex/model-catalogs/azure-gpt56-0.144.1.json" Note that ultra effort for foundry models not supported yet. The following settings are not added to config.toml: "use_responses_lite": false, "multi_agent_version": null They are changed inside: `` ~/.codex/model-catalogs/azure-gpt56-0.144.1.json ` Within the gpt-5.6-sol model entry (do similarly for remaining 5.6 family as well if you use them): { "slug": "gpt-5.6-sol", "use_responses_lite": false, "multi_agent_version": null } config.toml simply points Codex CLI to this patched model catalog. Use an absolute path for model_catalog_json`.

Analysis from my OpenClaw running GPT 5.6 Sol: This newer workaround is the best one posted so far. It’s targeted, transparent, and easy to reverse.

What it changes

In a copied model catalog, it changes GPT-5.6 Sol from:
"use_responses_lite": true,
"multi_agent_version": "v2"

to:

"use_responses_lite": false,
"multi_agent_version": null

Then config.toml points Codex at that custom catalog:
model_catalog_json = "/Users/bradgroux/.codex/model-catalogs/azure-gpt56-0.144.1.json"

Why it should work

• use_responses_lite: false avoids the Foundry Responses Lite incompatibility.
• multi_agent_version: null prevents Codex from injecting the rejected collaboration namespace.
• It doesn’t rewrite your entire config or manipulate feature flags.
• Removing one config line restores Codex’s normal catalog.

Tradeoffs

• Native Codex subagents/collaboration will be unavailable for that model.
• ultra reasoning relies on delegation and won’t work properly; use max.
• GPT-5.6 prompt caching may still be broken on Foundry, potentially making it expensive.
• The catalog is version-specific and should be regenerated after Codex upgrades.
• The JSON shown in the comment is only the changed model fragment. The actual file must be a complete export from codex debug models, not a three-field JSON file.

Recommendation: Use this approach if you want GPT-5.6 Sol working now. It is substantially safer than the generated one-liner and cleaner than downgrading multi-agent v2 to v1. Keep GPT-5.5 available for workloads where prompt caching or subagents matter.

Thanks for this! Confirmed working.

Independent confirmation on codex-cli 0.144.0-alpha.4 (bundled in the ChatGPT desktop app), Azure v1 Responses custom provider (base_url = "https://RESOURCE.openai.azure.com/openai/v1", wire_api = "responses"), deployments named exactly gpt-5.6-sol / gpt-5.6-terra / gpt-5.6-luna. gpt-5.5 through the same provider works before and after.

Two distinct rejections stack on Azure:

1. The bundled catalog sets use_responses_lite: true on all three GPT-5.6 entries, so the client stamps X-OpenAI-Internal-Codex-Responses-Lite regardless of provider and Azure rejects the tool set (this issue).
2. With responses-lite forced off via a catalog override, Sol and Terra still fail every turn with Invalid Value: 'tools'. Namespace 'collaboration' is reserved for encrypted tool use by this model. while Luna works. The catalog diff isolates it: Sol and Terra carry multi_agent_version: "v2", Luna carries "v1". Same failure as #31864 and #31875; #31882 identifies both flags.

Verified workaround (all three models then complete turns on Azure):

1. Extract the embedded {"models":[...]} catalog JSON from the codex binary.
2. On the three gpt-5.6-* entries set "use_responses_lite": false and "multi_agent_version": "v1".
3. Reference it with model_catalog_json = "/path/to/patched-catalog.json" in ~/.codex/config.toml. Note it replaces the bundled catalog, so keep the other model entries in the file.

Suggested fix: default both behaviors off when model_provider is not the built-in OpenAI provider, since neither the lite endpoint nor the encrypted collaboration namespace exists on third-party Responses backends.

Desktop caveat: even with the patched catalog, the desktop picker will not list the 5.6 models until the account-side rollout flag flips (#19694), so testing has to go through CLI profiles or -m.

To work around this on Desktop Codex GUI I created a local proxy that forces the model change. You can work with Codex to build one.

Hit the same error on macOS with codex-cli 0.144.1 + Azure Foundry (gpt-5.6-sol, Global Standard, api-version 2025-04-01-preview). I worked through this with Claude (Claude Code), which did the debugging below — capturing codex's outgoing request through a local proxy, diffing the built-in model catalog entries, and testing the workaround — and drafted this comment. I've verified the workaround works on my machine.

Root cause

The built-in model catalog entry for gpt-5.6-sol has use_responses_lite: true and multi_agent_version: "v2". That combination makes codex:

1. send the x-openai-internal-codex-responses-lite: true header, and
2. include a namespace-type tool (collaboration, the sub-agent tools) in the additional_tools item.

Azure's Responses-Lite validation only accepts function / custom / client-executed tool search, so every turn 400s with param: "tools", code: "unsupported_value". The same catalog gives gpt-5.5 use_responses_lite: false and multi_agent_version: null, which is why 5.5 works on Azure and 5.6-sol doesn't. Presumably OpenAI's own lite backend accepts the namespace tool, but Azure's doesn't (yet).

Note: --disable multi_agent does not remove the namespace tool, so there's no config-level escape hatch short of overriding the catalog.

Workaround

Override the catalog entry so Azure gets the full Responses path, same as gpt-5.5:

1. Extract the baked-in catalog from the binary and flip two fields (script courtesy of Claude):

import os, subprocess, json
binpath = os.path.realpath(subprocess.check_output(["which", "codex"]).decode().strip())
data = open(binpath, "rb").read()
start = data.find(b'{\n "models": [\n {\n "slug": "gpt-5.6-sol"')
depth, i = 0, start
while True:
if data[i] == ord("{"): depth += 1
elif data[i] == ord("}"):
depth -= 1
if depth == 0: break
i += 1
cat = json.loads(data[start:i+1])
for m in cat["models"]:
if m["slug"] == "gpt-5.6-sol":
m["use_responses_lite"] = False
m["multi_agent_version"] = None
with open(os.path.expanduser("~/.codex/model-catalog-override.jso
json.dump(cat, f, indent=2)

1. Point config at it in ~/.codex/config.toml:

model_catalog_json = "/Users/<you>/.codex/model-catalog-override.json"

1. If you see Model metadata for 'gpt-5.6-sol' not found warnings, also delete a stale ~/.codex/models_cache.json (mine was months old and pre-dated 5.5/5.6).

With that in place, gpt-5.6-sol works on Azure, including tool calls. Caveats: the override pins metadata for all models (re-extract after upgrading codex), and
it disables the v2 sub-agent collaboration tools for this model —way.

Suggested fix: either gate use_responses_lite/namespace tools on backend), or drop the namespace tool from the payload when the lite header is set for a provider that doesn't support it.

python -c "import json,os,re,shutil,subprocess,tempfile; from pathlib import Path; d=Path.home()/'.codex'; d.mkdir(parents=True,exist_ok=True);
exe=shutil.which('codex') or 'codex'; td=tempfile.TemporaryDirectory(); env=os.environ.copy(); env['CODEX_HOME']=td.name; data=json.
loads(subprocess.check_output([exe,'debug','models'] if os.name!='nt' else '\"'+exe+'\" debug models',env=env,encoding='utf-8',shell=os.
name=='nt')); td.cleanup(); model=next((x for x in data.get('models',[]) if x.get('slug')=='gpt-5.6-sol'),None); model is not None or (_ for _ in
()).throw(SystemExit('gpt-5.6-sol not found in Codex model catalog')); model['use_responses_lite']=False; model['multi_agent_version']='v1';
catalog=d/'models.azure.json'; tmp=d/'models.azure.json.tmp'; tmp.write_text(json.dumps(data,indent=2)+'\n',encoding='utf-8'); os.replace(tmp,
catalog); cfg=d/'config.toml'; old=cfg.read_text(encoding='utf-8') if cfg.exists() else ''; cfg.exists() and shutil.copy2(cfg,str(cfg)+'.bak');
first=re.search(r'(?m)^[ \t]*\[',old); head=old[:first.start()] if first else old; tail=old[first.start():] if first else ''; head=re.sub(r'(?m)^[
\t]*(?:model|model_catalog_json)[ \t]*=.*(?:\n|$)','',head); text='model = \"gpt-5.6-sol\"\nmodel_catalog_json = '+json.dumps(catalog.as_posix())+
'\n'+head+tail; text+='' if text.endswith('\n') else '\n'; settings='multi_agent = true\nmulti_agent_v2 = false\n'; section=re.compile(r'(?ms)^([
\t]*\[features\][ \t]*(?:#.*)?\n)(.*?)(?=^[ \t]*\[|\Z)'); text=section.sub(lambda m:m.group(1)+settings+re.sub(r'(?m)^[ \t]*multi_agent(?:_v2)?[
\t]*=.*(?:\n|$)','',m.group(2)),text,count=1) if section.search(text) else text+'\n[features]\n'+settings; ctmp=d/'config.toml.tmp'; ctmp.
write_text(text,encoding='utf-8'); os.replace(ctmp,cfg); print('Codex Azure workaround installed; fully restart Codex/VS Code and start a new
conversation.')"

One Line Fix for Windows

Verified workaround on macOS + Azure Foundry (codex-cli 0.144.1)

Can reproduce the exact error on Azure with gpt-5.6-sol:

{
  "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"
  }
}

gpt-5.5 works on the same Azure provider/config. Switching to gpt-5.6-sol fails every turn.

Root cause (matches prior reports)

The bundled catalog marks gpt-5.6-sol / gpt-5.6-terra / gpt-5.6-luna with:

• use_responses_lite: true
• multi_agent_version: "v2" (Sol/Terra) or "v1" (Luna)
• tool_mode: "code_mode_only"

That makes Codex send the Responses-Lite header and inject the collaboration namespace tool. Azure's Responses backend rejects that tool set. Older models like gpt-5.5 have use_responses_lite: false and multi_agent_version: null, which is why they work.

Workaround that fixed it for me

1. Export the full bundled catalog:

codex debug models > ~/.codex/model-catalog.json

1. Patch all gpt-5.6-* entries:

"use_responses_lite": false,
"multi_agent_version": null,
"tool_mode": null

1. Point config at the override:

model_catalog_json = "/Users/<you>/.codex/model-catalog.json"

1. Restart Codex.

Verification

After the override:

• gpt-5.5 on Azure: works
• gpt-5.6-sol on Azure: works (including tool calls)
• codex exec -c model='"gpt-5.6-sol"' "Reply with exactly: sol-azure-ok" succeeds end-to-end

Provider config used:

model_provider = "azure"

[model_providers.azure]
base_url = "https://<resource>.services.ai.azure.com/openai/v1"
env_key = "AZURE_API_KEY"
wire_api = "responses"

Suggested fix

For non-OpenAI providers (Azure/custom model_provider), Codex should probably default use_responses_lite and collaboration namespace tools off, or gate them on backend capability detection. Right now the catalog assumes OpenAI's lite backend, which breaks third-party Responses providers.

Caveats

• Native v2 sub-agent/collaboration tools are disabled with this override
• Re-export the catalog after Codex upgrades (override replaces bundled metadata)
• model_catalog_json must be the full catalog from codex debug models, not a partial JSON fragment

Happy to test a proper provider-gated fix if maintainers want another Azure validation pass.

In this thread someone said that completely deleting the config.toml helped also https://github.com/openai/codex/issues/30224

Works on v144.0

@smr0x as in they fixed it?

@thiagoperes no, you either don't update the cli to latest version, or set it 5.5, and tell it to apply this fix: https://github.com/openai/codex/issues/31870#issuecomment-4944619659

The fix uses both config.toml and a patched model catalog JSON. In ~/.codex/config.toml, add: model_reasoning_effort = "max" model_catalog_json = "/Users/username/.codex/model-catalogs/azure-gpt56-0.144.1.json" Note that ultra effort for foundry models not supported yet. The following settings are not added to config.toml: "use_responses_lite": false, "multi_agent_version": null They are changed inside: `` ~/.codex/model-catalogs/azure-gpt56-0.144.1.json ` Within the gpt-5.6-sol model entry (do similarly for remaining 5.6 family as well if you use them): { "slug": "gpt-5.6-sol", "use_responses_lite": false, "multi_agent_version": null } config.toml simply points Codex CLI to this patched model catalog. Use an absolute path for model_catalog_json`.

The model_catalog_json change worked for me.

The fix offered here seems to disable prompt caching and results in very expensive usage.

Hello, I share the concern about cost. The catalog patch appears to work by disabling use_responses_lite; if that also disables prompt caching, it is not a viable production workaround.

A better temporary approach is to place LiteLLM in front of Azure and point Codex to a local, OpenAI-compatible LiteLLM endpoint rather than patching Codex’s model catalog.

Codex configuration:

model_provider = "litellm_gpt56"

[model_providers.litellm_gpt56]
base_url = "http://127.0.0.1:4000/v1"
env_key = "LITELLM_MASTER_KEY"
wire_api = "responses"

LiteLLM configuration:

model_list:
  - model_name: gpt-5.6-sol
    litellm_params:
      model: azure/gpt-5.6-sol
      api_base: https://<azure-resource>.openai.azure.com/
      api_key: os.environ/AZURE_OPENAI_API_KEY
      api_version: os.environ/AZURE_OPENAI_API_VERSION

  - model_name: gpt-5.6-terra
    litellm_params:
      model: azure/gpt-5.6-terra
      api_base: https://<azure-resource>.openai.azure.com/
      api_key: os.environ/AZURE_OPENAI_API_KEY
      api_version: os.environ/AZURE_OPENAI_API_VERSION

With this setup, Codex communicates with LiteLLM through the local OpenAI-compatible endpoint, while LiteLLM translates requests for Azure. This avoids the current Azure issue involving the X-OpenAI-Internal-Codex-Responses-Lite header and tool-namespace handling, without modifying Codex’s bundled model metadata.

Do not assume it is cost-neutral without checking Azure usage data for cached input tokens. But unlike the catalog patch, this approach does not require setting use_responses_lite = false in Codex’s model catalog. That makes it the less brittle temporary workaround and more likely to preserve prompt-caching behavior until Codex adds proper Azure provider-capability support.

With this setup, Codex communicates with LiteLLM through the local OpenAI-compatible endpoint, while LiteLLM translates requests for Azure. This avoids the current Azure issue involving the X-OpenAI-Internal-Codex-Responses-Lite header and tool-namespace handling, without modifying Codex’s bundled model metadata. Do not assume it is cost-neutral without checking Azure usage data for cached input tokens. But unlike the catalog patch, this approach does not require setting use_responses_lite = false in Codex’s model catalog. That makes it the less brittle temporary workaround and more likely to preserve prompt-caching behavior until Codex adds proper Azure provider-capability support.

This isn't a better solution. The reason you have to disable lite is because it's enabled in the same version upgrade of codex that tells the cli what these models are. What you are doing is effectively the same thing but with extra steps.

The suggested changes here is probably not the cause of caching being broken. It looks like it's just broken on Azure for GPT 5.6. See this thread: https://learn.microsoft.com/en-in/answers/questions/5942997/gpt-5-6-implicit-prompt-caching-and-explicit-promp

So while the workarounds in this thread do allow you to use Codex with 5.6 on Azure Foundry, you don't get anything cached.

The suggested changes here is probably not the cause of caching being broken. It looks like it's just broken on Azure for GPT 5.6. See this thread: https://learn.microsoft.com/en-in/answers/questions/5942997/gpt-5-6-implicit-prompt-caching-and-explicit-promp So while the workarounds in this thread do allow you to use Codex with 5.6 on Azure Foundry, you don't get anything cached.

Azure actually had acknowledged the broken caching issue. Not a client problem.

Yes its a problem of prompt caching with azure on 5.6 models. Its such a bad experience to use openai models with azure.

It's such a bad experience to use azure*

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).

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 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.
<img width="2250" height="1310" alt="Image" src="https://github.com/user-attachments/assets/abc2a11f-3f8e-4fd1-9424-9b903c58e261" />

> > 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. <img alt="Image" width="2000" height="1164" src="https://private-user-images.githubusercontent.com/48279772/620619839-abc2a11f-3f8e-4fd1-9424-9b903c58e261.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODM5MTUyMzAsIm5iZiI6MTc4MzkxNDkzMCwicGF0aCI6Ii80ODI3OTc3Mi82MjA2MTk4MzktYWJjMmExMWYtM2Y4ZS00ZmQxLTk0MjQtOWI5MDNjNThlMjYxLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA3MTMlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwNzEzVDAzNTUzMFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTIyMDk4MzRjMTNjZjA4MTc4ZTM0NTAzYTg2OTNiNmIzYWQ1YmVkMmYzZWQzZmVjYjFjZTdjNmRiMmE1MjY2MDImWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.Ll7gxOANvDtk8w1eXQ40aPzOctPHOLJyKqGHeAZR3fs">

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.

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).

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
}

<img width="1728" height="924" alt="Image" src="https://github.com/user-attachments/assets/9822273c-a5d3-48d1-b9e7-479b5685eea8" />

> 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). 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 } <img alt="Image" width="1728" height="924" src="https://private-user-images.githubusercontent.com/1317141/621826955-9822273c-a5d3-48d1-b9e7-479b5685eea8.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODQwODI2MzIsIm5iZiI6MTc4NDA4MjMzMiwicGF0aCI6Ii8xMzE3MTQxLzYyMTgyNjk1NS05ODIyMjczYy1hNWQzLTQ4ZDEtYjllNy00NzliNTY4NWVlYTgucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI2MDcxNSUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNjA3MTVUMDIyNTMyWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9ZTA5YjczYTc4YmI5ODhiYjJkNWI3YmE1MjI1YmI0NWMyZjA1MWJjYWY3YmU1MDlkOTkzZjQ4YjdlNTFhNjcyNiZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmcmVzcG9uc2UtY29udGVudC10eXBlPWltYWdlJTJGcG5nIn0.5ler5--uv0iZOxVYLSdikkdOHUNOnUPOmydqafz_4uQ">

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.

> > 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). > > > 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 > } > <img alt="Image" width="1728" height="924" src="https://private-user-images.githubusercontent.com/1317141/621826955-9822273c-a5d3-48d1-b9e7-479b5685eea8.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODQwODI2MzIsIm5iZiI6MTc4NDA4MjMzMiwicGF0aCI6Ii8xMzE3MTQxLzYyMTgyNjk1NS05ODIyMjczYy1hNWQzLTQ4ZDEtYjllNy00NzliNTY4NWVlYTgucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI2MDcxNSUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNjA3MTVUMDIyNTMyWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9ZTA5YjczYTc4YmI5ODhiYjJkNWI3YmE1MjI1YmI0NWMyZjA1MWJjYWY3YmU1MDlkOTkzZjQ4YjdlNTFhNjcyNiZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmcmVzcG9uc2UtY29udGVudC10eXBlPWltYWdlJTJGcG5nIn0.5ler5--uv0iZOxVYLSdikkdOHUNOnUPOmydqafz_4uQ"> 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

> > > 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). > > > > > > 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 > > } > > <img alt="Image" width="816" height="436.328125" src="https://private-user-images.githubusercontent.com/1317141/621826955-9822273c-a5d3-48d1-b9e7-479b5685eea8.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODQwODI2MzIsIm5iZiI6MTc4NDA4MjMzMiwicGF0aCI6Ii8xMzE3MTQxLzYyMTgyNjk1NS05ODIyMjczYy1hNWQzLTQ4ZDEtYjllNy00NzliNTY4NWVlYTgucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI2MDcxNSUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNjA3MTVUMDIyNTMyWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9ZTA5YjczYTc4YmI5ODhiYjJkNWI3YmE1MjI1YmI0NWMyZjA1MWJjYWY3YmU1MDlkOTkzZjQ4YjdlNTFhNjcyNiZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmcmVzcG9uc2UtY29udGVudC10eXBlPWltYWdlJTJGcG5nIn0.5ler5--uv0iZOxVYLSdikkdOHUNOnUPOmydqafz_4uQ"> > > > 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.

> > > > 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). > > > > > > > > > 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 > > > } > > > <img alt="Image" width="816" height="436.328125" src="https://private-user-images.githubusercontent.com/1317141/621826955-9822273c-a5d3-48d1-b9e7-479b5685eea8.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODQwODI2MzIsIm5iZiI6MTc4NDA4MjMzMiwicGF0aCI6Ii8xMzE3MTQxLzYyMTgyNjk1NS05ODIyMjczYy1hNWQzLTQ4ZDEtYjllNy00NzliNTY4NWVlYTgucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI2MDcxNSUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNjA3MTVUMDIyNTMyWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9ZTA5YjczYTc4YmI5ODhiYjJkNWI3YmE1MjI1YmI0NWMyZjA1MWJjYWY3YmU1MDlkOTkzZjQ4YjdlNTFhNjcyNiZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmcmVzcG9uc2UtY29udGVudC10eXBlPWltYWdlJTJGcG5nIn0.5ler5--uv0iZOxVYLSdikkdOHUNOnUPOmydqafz_4uQ"> > > > > > > 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!

> > > > > 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). > > > > > > > > > > > > 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 > > > > } > > > > <img alt="Image" width="816" height="436.328125" src="https://private-user-images.githubusercontent.com/1317141/621826955-9822273c-a5d3-48d1-b9e7-479b5685eea8.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODQwODI2MzIsIm5iZiI6MTc4NDA4MjMzMiwicGF0aCI6Ii8xMzE3MTQxLzYyMTgyNjk1NS05ODIyMjczYy1hNWQzLTQ4ZDEtYjllNy00NzliNTY4NWVlYTgucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI2MDcxNSUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNjA3MTVUMDIyNTMyWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9ZTA5YjczYTc4YmI5ODhiYjJkNWI3YmE1MjI1YmI0NWMyZjA1MWJjYWY3YmU1MDlkOTkzZjQ4YjdlNTFhNjcyNiZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmcmVzcG9uc2UtY29udGVudC10eXBlPWltYWdlJTJGcG5nIn0.5ler5--uv0iZOxVYLSdikkdOHUNOnUPOmydqafz_4uQ"> > > > > > > > > > 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](https://github.com/Hyacehila/codex-provider-compat) ; 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 ?

> > > > > > 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). > > > > > > > > > > > > > > > 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 > > > > > } > > > > > <img alt="Image" width="816" height="436.328125" src="https://private-user-images.githubusercontent.com/1317141/621826955-9822273c-a5d3-48d1-b9e7-479b5685eea8.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODQwODI2MzIsIm5iZiI6MTc4NDA4MjMzMiwicGF0aCI6Ii8xMzE3MTQxLzYyMTgyNjk1NS05ODIyMjczYy1hNWQzLTQ4ZDEtYjllNy00NzliNTY4NWVlYTgucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI2MDcxNSUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNjA3MTVUMDIyNTMyWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9ZTA5YjczYTc4YmI5ODhiYjJkNWI3YmE1MjI1YmI0NWMyZjA1MWJjYWY3YmU1MDlkOTkzZjQ4YjdlNTFhNjcyNiZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmcmVzcG9uc2UtY29udGVudC10eXBlPWltYWdlJTJGcG5nIn0.5ler5--uv0iZOxVYLSdikkdOHUNOnUPOmydqafz_4uQ"> > > > > > > > > > > > > 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](https://github.com/Hyacehila/codex-provider-compat) ; 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.

> > > > > > > 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). > > > > > > > > > > > > > > > > > > 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 > > > > > > } > > > > > > <img alt="Image" width="816" height="436.328125" src="https://private-user-images.githubusercontent.com/1317141/621826955-9822273c-a5d3-48d1-b9e7-479b5685eea8.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODQwODI2MzIsIm5iZiI6MTc4NDA4MjMzMiwicGF0aCI6Ii8xMzE3MTQxLzYyMTgyNjk1NS05ODIyMjczYy1hNWQzLTQ4ZDEtYjllNy00NzliNTY4NWVlYTgucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI2MDcxNSUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNjA3MTVUMDIyNTMyWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9ZTA5YjczYTc4YmI5ODhiYjJkNWI3YmE1MjI1YmI0NWMyZjA1MWJjYWY3YmU1MDlkOTkzZjQ4YjdlNTFhNjcyNiZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmcmVzcG9uc2UtY29udGVudC10eXBlPWltYWdlJTJGcG5nIn0.5ler5--uv0iZOxVYLSdikkdOHUNOnUPOmydqafz_4uQ"> > > > > > > > > > > > > > > > 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](https://github.com/Hyacehila/codex-provider-compat) ; 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.