tool_search results reuse the same namespace name, hard-failing the thread with Duplicate namespace name 'mcp__*'

What version of the Codex App are you using (From “About Codex” dialog)?

26.903.8094.0 (Windows). Bundled Codex core: codex-cli 0.153.4.

What subscription do you have?

None - this install is configured with a third-party model provider through an API key, not an OpenAI subscription.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Requests fail with:

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

When the model calls tool_search more than once in a single turn, each result is stored in the conversation as a tool_search_output item, and each of those items carries a tool entry of type "namespace" named mcp__. Two searches in one turn therefore put two entries with the same namespace name into a single request, and the whole request is rejected.

This is not a one-off failure. The duplicate entry stays in the thread history, so every later turn in that thread fails with the same error at the same index (input[10]). Restarting the app does not help - only starting a new thread recovers.

What steps can reproduce the bug?

1. Configure one MCP server in ~/.codex/config.toml so its tools are exposed as deferred mcp__ tools. In my case: rednote (stdio, Node.js). I hit the same bug earlier with playwright.
2. In a single turn, let the model issue two tool_search calls (two parallel calls with different queries work well - e.g. one searching for "login", another for "get_note_content"). Both results contain the same mcp__rednote namespace.
3. Send any subsequent request in that thread. It fails with the error above and keeps failing on every following turn.

Session ids:

• rednote case: session 01a0890d-c295-76d1-9b02-2cdc23fbe30e, turn 01a0890d-c8cc-7710-b387-de0e2cd91d67, error at input[10]
• playwright case: session 2026-09-10T09-59-20-01a0890a-7be4-70e1-ba54-f1eb5e7d848e, turn 01a0890a-8401-7710-ad47-106c2123eac6, error at input[37], repeated on four later turns

In both cases the two tool_search_output items share the same turn_id and were produced in the same millisecond, which is what makes them parallel tool_search calls.

What is the expected behavior?

Tool-search results should be merged or deduplicated by namespace name before the conversation history is sent, or at minimum the same namespace should not appear twice in one request. It would also help if a rejected request did not permanently poison the thread, so that the session stays usable after the error.

Additional information

Evidence (abridged; the full sanitized log excerpt is attached as codex-issue-attachment-minimal-repro.txt):

Case A - mcp__rednote, two tool_search_output items inside turn 01a0890d-c8cc-7710-b387-de0e2cd91d67 (both at 2026-09-10T02:02:58.677Z):

{"type":"tool_search_output","call_id":"call_00_...","status":"completed","execution":"client","tools":[{"type":"namespace","name":"mcp__rednote","tools":[{"type":"function","name":"login", ...}]}]}
{"type":"tool_search_output","call_id":"call_01_...","status":"completed","execution":"client","tools":[{"type":"namespace","name":"mcp__rednote","tools":[{"type":"function","name":"get_note_comments", ...},{"type":"function","name":"get_note_content", ...}]}]}

Case B - mcp__playwright: same pattern. Once the duplicate was in the history, four later turns in the same thread failed with the index (input[37]) unchanged.

Correlation on this machine: 3 of 3 turns that called tool_search twice ended with this error; no turn with a single tool_search call failed.

Configuration (redacted):

[mcp_servers.rednote]
command = '<node.exe>'
args = ['/rednote-mcp/dist/cli.js', "--stdio"]

[mcp_servers.rednote.env]
APPDATA = ''
NODE_OPTIONS = '--require=/patch_playwright.cjs'
NODE_PATH = '/node_modules'

[mcp_servers.playwright]
command = '<node.exe>'
args = ['/@playwright/mcp/cli.js']

Workaround I am using: keep tool_search to a single call per turn and request more tools with a larger limit instead of issuing a second search, and disable MCP servers that are not needed for the current task.

Related issues: #31744, #31746, #31748, #31665 (same namespace-duplication family).

One caveat: this install routes requests to a third-party Responses-compatible endpoint through a local proxy, so I cannot tell whether the namespace validation happens in OpenAI's API or in that endpoint. What I am reporting is the client-side behaviour: two identical namespace entries are serialized into one request's input array.

Start at the tool_search handling and conversation-history serialization, reproducing two parallel searches with the attached minimal log pattern. Trace how tool_search_output namespace entries are assembled before the next request; done means repeated searches no longer send duplicate namespace names and the thread remains usable after rejection.