--search does not inject web_search tool for gpt-5.6-terra/luna with a Responses-compatible custom provider, while gpt-5.5 works

What issue are you seeing?

When using Codex with a Responses-compatible custom provider and --search, Codex injects the native web_search tool for gpt-5.5, but does not inject any tools array for gpt-5.6-terra / gpt-5.6-luna.

As a result, the model cannot use native web search and returns WEB_SEARCH_UNAVAILABLE when explicitly instructed to only use the native web_search tool.

This appears to happen before the request reaches the provider. A local HTTP capture proxy showed that the Codex request body for gpt-5.6-terra contains tool_choice: "auto" but has no tools array at all.

Environment

• Codex Desktop app
• Codex CLI/runtime: 0.144.2
• macOS
• Provider type: custom provider using wire_api = "responses"
• Config shape:

model_provider = "custom_responses_provider"
model = "gpt-5.5"

[model_providers.custom_responses_provider]
base_url = "https://example.com/v1"
wire_api = "responses"
requires_openai_auth = true

Steps to reproduce

1. Configure a Responses-compatible custom provider.
2. Run Codex with search enabled using gpt-5.6-terra:

codex --search --model gpt-5.6-terra --ask-for-approval never --sandbox read-only exec --skip-git-repo-check \
  "Use only the Codex native web_search tool. Do not use shell, curl, browser, MCP, or local commands. If native web_search is unavailable, answer WEB_SEARCH_UNAVAILABLE."

1. Observe that the model answers WEB_SEARCH_UNAVAILABLE.
2. Capture the outgoing request body before it reaches the provider.
3. Compare with the same command using gpt-5.5.

Expected behavior

When --search is enabled and the selected model profile supports search, Codex should include the native web_search tool in the Responses request body for gpt-5.6-terra / gpt-5.6-luna, just as it does for gpt-5.5.

Actual behavior

For gpt-5.6-terra, Codex sends a Responses request with:

{
  "model": "gpt-5.6-terra",
  "stream": true,
  "tool_choice": "auto",
  "tools": null
}

The model then cannot call native web search and returns:

WEB_SEARCH_UNAVAILABLE

For gpt-5.5 under the same provider and same Codex runtime, Codex sends a request that includes tools, including web_search, and native search works.

Controlled comparison

Captured outgoing request summaries:

{
  "case": "Codex gpt-5.6-terra with --search",
  "model": "gpt-5.6-terra",
  "stream": true,
  "tool_choice": "auto",
  "tools_len": null,
  "has_web_search_tool": false,
  "has_prompt_cache_key": true
}

{
  "case": "Codex gpt-5.5 with --search",
  "model": "gpt-5.5",
  "stream": true,
  "tool_choice": "auto",
  "tools_len": 14,
  "tool_types": [
    "function",
    "function",
    "function",
    "function",
    "function",
    "function",
    "function",
    "custom",
    "function",
    "function",
    "function",
    "function",
    "tool_search",
    "web_search"
  ],
  "has_web_search_tool": true,
  "has_prompt_cache_key": true
}

Direct Responses API call to the same provider and same gpt-5.6-terra model succeeds when tools: [{ "type": "web_search" }] is explicitly provided:

{
  "case": "Direct Responses API gpt-5.6-terra",
  "model": "gpt-5.6-terra",
  "stream": true,
  "tool_choice": "auto",
  "tools_len": 1,
  "tool_types": ["web_search"],
  "has_web_search_tool": true
}

The direct API response stream includes response.web_search_call.* events.

Why this looks like a Codex tool injection issue

• The provider can handle web_search for gpt-5.6-terra when the tool is explicitly included.
• Codex includes web_search for gpt-5.5 with the same provider and same runtime.
• Codex does not include a tools array at all for gpt-5.6-terra, even with --search.
• codex debug models reports supports_search_tool: true for gpt-5.6-terra, gpt-5.6-luna, and gpt-5.5.

Impact

Native web search works with gpt-5.5 but silently becomes unavailable with gpt-5.6-terra / gpt-5.6-luna through the same custom Responses provider. This is confusing in Codex Desktop because the visible behavior looks like web search disappeared or the environment broke, while the actual issue is that the outgoing request lacks the web_search tool.