Duplicate namespace in `input[N].tools[]` breaks requests on strict Responses API (regression in 26.909)

Summary

Since updating to 26.909.12148, Codex intermittently builds a request whose tools array
declares the same tool namespace twice, causing any strict Responses-API implementation
to reject the whole request.

Environment

• Codex desktop (ChatGPT.app): 26.909.12148 (macOS)
• codex-cli: 0.152.0
• Provider: custom (Responses API), base_url = https://api.deepseek.com/
• Model: deepseek-flash
• Features enabled: apps, enable_mcp_apps, apps_mcp_path_override, tool_search,
  thread_tools, plugins, recommended_plugins

Error

{"error":{"message":"Duplicate namespace name 'mcp__davinci_resolve' in input[27].tools[0].
Namespace names must be unique.","type":"invalid_request_error","code":"invalid_request_error"}}

Also observed with a built-in namespace (no MCP involved):
{"error":{"message":"Duplicate namespace name 'codex_app' in input[1067].tools[0].
Namespace names must be unique.","type":"invalid_request_error"}}

Steps to reproduce

1. Have an MCP server configured (e.g. davinci_resolve) and apps enabled.
2. Use a Responses-API provider that validates namespace uniqueness (e.g. DeepSeek).
3. Start a new conversation and invoke/reference the MCP tool.
4. Request is rejected with the error above.

Expected

Request is accepted — each tool namespace is declared exactly once.

Actual

The tools array inside an input item declares the same namespace twice
(e.g. input[13].tools[0], input[27].tools[0]), and the request is rejected.

Analysis

• Not a configuration issue: the same error occurs with codex_app (an app/app-server
  namespace) in tasks that never touch the MCP server -> the duplication is in Codex's
  own request construction.
• Matches the behavior described in the binary: "An installed app's MCP tools are either
  provided to you already, or can be lazy-loaded through the tool_search tool."
  A tool can be supplied BOTH directly and via tool_search -> duplicate namespace.
• Related internal features: tool_search, enable_mcp_apps, tool_search_always_defer_mcp_tools,
  apps_mcp_path_override, thread_tools.
• The same task over a relay (chat/completions conversion) does NOT error, because the
  namespace structure is transformed away — only native Responses endpoints surface it.

Version bisect

26.905.11957 -> OK (no error for weeks)
26.909.12148 -> broken (reproducible, several times/day)

Impact

Blocks MCP / app-tool usage on strict Responses-API providers (the request hard-fails).

Suggested fix

Ensure a tool namespace is emitted only once in the assembled tools array —
i.e. if an app's MCP tools are provided directly, do not also include them via
tool_search output (or de-duplicate by namespace before sending).

Trace Codex's request-construction path for native Responses API requests, focusing on tool_search, enable_mcp_apps, thread_tools, and app MCP tool assembly. Reproduce with a strict Responses-API provider and inspect whether directly supplied tools and tool_search output share a namespace. Done means each namespace appears only once and MCP/app requests are accepted without regressions.