Codex CLI with Azure OpenAI gpt-5.6-sol fails due to Codex-specific tools / collaboration namespace

Open 💬 4 comments Opened Jul 9, 2026 by Soorma718

What version of Codex CLI is running?

0.144.0

What subscription do you have?

Azure API

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Linux / WSL

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

Ghostty

Codex doctor report

What issue are you seeing?

Azure deployment:

``text gpt-5.6-sol``

Model version:

``text 2026-07-09``

Deployment type:

``text Global Standard``

Azure portal target URI:

``text https://************.cognitiveservices.azure.com/openai/responses?api-version=2025-04-01-preview``

Relevant Codex config

```toml
model = "gpt-5.6-sol"
model_provider = "azure"
model_reasoning_effort = "max"
web_search = "disabled"

[model_providers.azure]
name = "Azure OpenAI"
base_url = "************.cognitiveservices.azure.com/openai"
env_key = "AZURE_OPENAI_API_KEY"
wire_api = "responses"
query_params = { "api-version" = "2025-04-01-preview" }
```

I also tested with:

``toml base_url = "https://************.cognitiveservices.azure.com/openai/v1" wire_api = "responses"``

### What works

A direct Azure Responses API call to the portal-provided endpoint works successfully.

Example request:

``http POST https:/***************.azure.com/openai/responses?api-version=2025-04-01-preview api-key: <redacted> Content-Type: application/json``

Payload:

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

Response succeeds and returns:

``text OK``

I also tested Azure-supported reasoning efforts:

``text none works low works medium works high works xhigh works max works ultra rejected by Azure``

So the Azure deployment, endpoint, key, and model are valid.

### What fails in Codex

Running Codex CLI against the same Azure deployment fails before the model can answer.

Example:

``bash codex exec \ --ephemeral \ --skip-git-repo-check \ -c 'model_provider="azure"' \ -c 'model_providers.azure.name="Azure OpenAI"' \ -c 'model_providers.azure.base_url="**********.cognitiveservices.azure.com/openai"' \ -c 'model_providers.azure.env_key="AZURE_OPENAI_API_KEY"' \ -c 'model_providers.azure.wire_api="responses"' \ -c 'model_providers.azure.query_params={"api-version"="2025-04-01-preview"}' \ -c 'web_search="disabled"' \ -c 'model_reasoning_effort="high"' \ "Reply exactly: OK"``

Error:

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

### Additional debugging

I put a localhost proxy between Codex and Azure to inspect the outgoing request.

Codex sends a Responses API payload containing input items of type:

``json { "type": "additional_tools", "role": "developer", "tools": [...] }``

The included additional tools were:

``text exec wait request_user_input collaboration``

The collaboration entry is a namespace tool:

``json { "type": "namespace", "name": "collaboration", "description": "Tools for spawning and managing sub-agents." }``

When forwarding this request to Azure after stripping Codex-only headers, Azure rejects it with:

``json { "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 the proxy removes only the collaboration namespace tool and forwards the rest of the request to Azure, Codex works successfully, including normal
shell tool use.

For example, after stripping the collaboration namespace, this works:

``bash codex exec "Use shell to run pwd, then reply with only the resulting path."``

Codex successfully runs:

``bash pwd``

and returns the expected path.

### Expected behavior

Codex should support Azure OpenAI Responses deployments such as gpt-5.6-sol without sending Azure-incompatible internal headers or unsupported tool
namespace declarations.

At minimum, when model_provider is a custom/Azure provider, Codex should either:

avoid sending X-OpenAI-Internal-Codex-Responses-Lite, or
avoid sending hosted/internal Codex-only tool formats to Azure, or
feature-detect / config-gate the collaboration namespace tool, or
provide a config option to disable collaboration/multi-agent tool injection for providers that reject it.

### Actual behavior

Codex sends provider-incompatible internal/tool metadata, causing Azure to reject the request even though the same model/deployment works through the
Azure Responses API directly.

### Workaround

A local proxy can make it work by:

forwarding requests to:

``text https://*********************.azure.com/openai/responses?api-version=2025-04-01-preview``

forwarding only minimal auth/content headers,
removing the collaboration namespace from additional_tools.

With that workaround, Codex works with:

``text gpt-5.6-sol reasoning.effort = max``

but native Codex subagents / collaboration cannot work because the rejected namespace has to be stripped.

### Request

Could Codex add proper Azure OpenAI Responses support for current GPT-5.6 Azure deployments, especially:

no X-OpenAI-Internal-Codex-Responses-Lite behavior for Azure/custom providers,
no Azure-incompatible collaboration namespace tool unless supported,
a config flag to disable collaboration/multi-agent additional tools,
support for Azure preview Responses endpoint format:

``text /openai/responses?api-version=2025-04-01-preview``

support for model_reasoning_effort = "max" for models that accept it.

Direct Azure API calls confirm that gpt-5.6-sol itself works and accepts max; the failure appears to be Codex request-shaping/tooling compatibility, not
the Azure deployment.

What steps can reproduce the bug?

Running Codex CLI against the same Azure deployment fails before the model can answer.

Example:

Error:

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗