Codex tool_search deferred MCP tools and the supports_search_tool catalog flag

Facts

• This ANSWERS the open question in codex-model-catalog-json-model-catalog-json-for.md: setting `supports_search_tool` to false in a catalog entry made Codex 0.145.0 to 0.147.0 register MCP tools as direct tools and show them in a new session, on three independent Windows and Linux reports. [source]
• Codex computes `search_tool_enabled` as `model_info.supports_search_tool && provider.capabilities().namespace_tools` in `codex-rs/core/src/tools/spec_plan.rs`. [source]
• When `search_tool_enabled` is true, `codex-rs/core/src/mcp_tool_exposure.rs` registers every MCP tool as `ToolExposure::Deferred`, and `build_model_visible_specs*` emits only tools whose exposure is direct. [source]
• `tool_mode: null` with no code-mode feature flag resolves to `ToolMode::Direct`, so no code-mode exec tool exists to hold deferred tools. [source]
• DeepSeek's official Codex setup script hardcodes `"supports_search_tool": true` and `"tool_mode": null` in the `~/.codex/models.json` it writes, for `deepseek-v4-flash`, `deepseek-v4-pro` and a free variant. [source]
• With that catalog and an MCP server, the session showed web search and MCP resource tools but no `mcp__*` tools and no `tool_search`, even though `codex mcp list` showed the stdio server enabled and the MCP handshake succeeded. [source]
• Hosted web search stayed available with the flag set false, because it follows provider capabilities and `web_search_tool_type`, not `supports_search_tool`. [source]
• A reporter behind a LiteLLM to sglang router found that with the flag true Codex sends `type: "tool_search"` with no `function` field, LiteLLM's Responses-to-chat translation answers `400: Field required ... tools[13].function`, and a rewrite to a plain function fails in Codex with `tool_search handler received unsupported payload` (`core/src/tools/handlers/tool_search.rs`). [source]
• The same reporter found `supports_search_tool: false` did not expose MCP tools on that LiteLLM route, and suspected `provider.capabilities().namespace_tools` or `tool_mode` also gate exposure. [source]
• With `multi_agent_version: "v1"`, Codex registers the V1 multi-agent tools as deferred behind `tool_search`; `deepseek-v4-flash` does not recognise or call `tool_search`, so those tools are unreachable too. [source]
• `deepseek-v4-flash` answered a missing MCP tool by calling `list_mcp_resources`, seeing only `codex_apps`, and concluding no tool existed, so naming a tool in the prompt did not trigger a deferred call. [source]
• A fork commit dated 2026-08-03 titled "fix: keep MCP tools direct for unsupported search providers (#36382)" implements the direct-exposure fallback in a fork; no upstream merge is shown. [source]
• The same router reporter found its message coalescing dropped DeepSeek's `reasoning_content` on follow-up turns, producing `400: The reasoning_content in the thinking mode must be passed back to the API` from sglang whenever a tool call happened. [source]
• OpenAI's guide says `tool_search` is supported only on `gpt-5.4` and later in the Responses API, and that discovered tools are injected at the end of the context window to preserve the cache. [source]
• OpenAI recommends namespaces or MCP servers over bare deferred functions for tool search because the models were mostly trained to search those surfaces, and says a bare deferred function still shows its name and description, so only the parameter schema is deferred. [source]
• OpenAI advises keeping each namespace under 10 functions, and says `defer_loading` applies to the functions inside a namespace, not to the namespace object. [source]