0.147.0 regression: Azure Responses rejects empty functions namespace description #37380

What version of Codex CLI is running?

codex-cli 0.147.0

What subscription do you have?

Azure OpenAI through a custom Responses provider (routed through Azure API Management).

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

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

VS Code integrated terminal / PowerShell.

Codex doctor report

Not included because the issue is reproducible from the serialized HTTP payload and contains no authentication or connectivity failure.

What issue are you seeing?

Codex CLI 0.147.0 fails before the model can answer when using an Azure OpenAI Responses provider:

{
  "error": {
    "message": "Invalid 'input[0].tools[0].description': empty string. Expected a string with minimum length 1, but got an empty string instead.",
    "type": "invalid_request_error",
    "param": "input[0].tools[0].description",
    "code": "empty_string"
  }
}

The serialized request contains this first input item:

{
  "type": "additional_tools",
  "role": "developer",
  "tools": [
    {
      "type": "namespace",
      "name": "functions",
      "description": "",
      "tools": [
        {
          "type": "custom",
          "name": "exec",
          "description": "Run JavaScript code to orchestrate/compose tool calls..."
        }
      ]
    }
  ]
}

Azure's NamespaceToolParam schema requires description and specifies minLength: 1:
https://learn.microsoft.com/rest/api/microsoft-foundry/azureopenai/responses#openainamespacetoolparam

This is a regression from 0.146.0. With the same provider, model, authentication, and prompt, 0.146.0 sends the exec custom tool directly without the empty functions namespace and succeeds.

Disabling only code_mode_host does not work around the issue in 0.147.0; the empty namespace remains in the serialized request.

What steps can reproduce the bug?

Configure a custom Azure OpenAI Responses provider:

model_provider = "azure"
model = "gpt-5.6-sol"

[model_providers.azure]
name = "Azure OpenAI"
base_url = "https://<azure-or-gateway-endpoint>/openai/v1"
wire_api = "responses"

Then run:

codex exec --ephemeral --skip-git-repo-check "Reply with exactly: OK"

Observed comparison:

• 0.146.0: succeeds and returns OK.
• 0.147.0: returns the input[0].tools[0].description validation error above.

I captured the failing 0.147.0 request and replayed it against the same endpoint, changing only:

"description": "Default Codex tools."

The otherwise identical request returned HTTP 200. This confirms the empty namespace description is the direct cause.

The regression appears related to #37022, which grouped default tools under the functions namespace:
#37022

What is the expected behavior?

Codex should serialize the default functions namespace with a non-empty description, for example:

"description": "Default Codex tools."

Alternatively, it should avoid the namespace wrapper for providers that do not advertise support for that request shape.

Additional information

Related provider compatibility reports:

• Codex CLI with Azure OpenAI gpt-5.6-sol fails due to Codex-specific tools / collaboration namespace #31875
• gpt-5.6-sol/terra/luna hardcode use_responses_lite / multi_agent_version, causing 400s on Azure (and likely any non-ChatGPT-backend) model_provider #31882
• Custom Responses provider intermittently fails with native namespace tool routing errors #32318

This report is narrower: it specifically covers the 0.146.0 to 0.147.0 regression introduced by serializing the new functions namespace with an empty required description.