MCP tool schema mismatch: structured args are surfaced as strings for Hindsight retain

What version of Codex CLI is running?

codex-cli 0.118.0

What subscription do you have?

chatGPT Pro

Which model were you using?

gpt-5.4

What platform is your computer?

Darwin 25.4.0 arm64 arm

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

WarpTerminal v0.2026.04.01.08.39.stable_02

What issue are you seeing?

The MCP tool binding for Hindsight retain appears to surface structured arguments with the wrong shape on the Codex side.

Expected from the live MCP server schema:

• tags: array<string> | null
• metadata: object<string,string> | null

But in Codex, the tool binding behaves as if these fields were strings. This causes the first tool call to frequently send JSON-stringified values such as:

• tags: "[\"tooling\",\"hindsight\",\"codex\"]"
• metadata: "{\"source\":\"profiling\"}"

That then fails with:
1 validation error for call[retain]
tags
Input should be a valid list [type=list_type, input_value='[...]', input_type=str]

and similarly for metadata:
Input should be a valid dictionary

Important detail:
I verified this is not a Hindsight server bug.
The live Hindsight MCP server exposes the correct schema on /mcp/, and a direct MCP Python client works correctly when sending native types:

• tags as a real array
• metadata as a real object

So the likely bug is in the Codex MCP tool schema/binding layer, which is incorrectly surfacing array/object arguments as strings for this tool.

Repro:

1. Connect Hindsight MCP server
2. Call retain with tags/metadata
3. Observe that Codex tends to pass JSON-stringified values first
4. Tool call fails with Pydantic validation errors

What steps can reproduce the bug?

Uploaded thread: 019d52a0-636d-7eb3-9089-5a8a6df2abae

What is the expected behavior?

Codex should preserve MCP JSON Schema types faithfully and expose:

• tags as array
• metadata as object

Likely affected schema pattern:

• anyOf [array, null]
• anyOf [object, null]

Additional information

_No response_