Codex App sends tool_search_call.arguments as a JSON string, causing Responses API invalid_type errors

codex_fix.zip Man, that JSON stringification bug is a total pain. I ran into the same thing with the CLI and found that the parser was tripping over the double-encoded strings. I put together this little script that forces the object cast before the API request hits.

Is it a virus?

@u2bo Bugs around tool invocation are often harder to diagnose than they look because the failure isn't always the serialization itself it can be difficult to reconstruct the exact sequence of reasoning, argument generation, validation, and execution. Having a trace of every tool call with the generated arguments before execution makes these issues much easier to isolate.

@u2bo Bugs around tool invocation are often harder to diagnose than they look because the failure isn't always the serialization itself it can be difficult to reconstruct the exact sequence of reasoning, argument generation, validation, and execution. Having a trace of every tool call with the generated arguments before execution makes these issues much easier to isolate.

We’ve obtained the critical parameters triggering the aforementioned error, which perfectly match the description: tool call generated arguments before execution.

The two latest sets of critical parameters are shown below:

{
  "input_index": 28,
  "type": "tool_search_call",
  "call_id": "call_H91Re6731TtEVu1BXFJJ2cuf",
  "arguments_type": "string",
  "arguments": "{\"query\":\"chrome devtools network request list get current page navigate click input\",\"limit\":10}"
}

{
  "input_index": 62,
  "type": "tool_search_call",
  "call_id": "call_Q5wet5GUYIcEiweMrZO8jJjO",
  "arguments_type": "string",
  "arguments": "{\"limit\":10,\"query\":\"spawn agent wait agent subagent multi agent\"}"
}

These two payloads were generated right before the error occurred. The root cause is straightforward: the field tool_search_call.arguments is expected to be a JSON object, but it is being serialized as an escaped string in practice.

Expected format

"arguments": {
  "query": "spawn agent wait agent subagent multi agent",
  "limit": 10
}

Actual faulty format

"arguments": "{\"limit\":10,\"query\":\"spawn agent wait agent subagent multi agent\"}"

Three layers of local evidence are available for forensic analysis:

1. rollout*.jsonl: Contains response_item -> tool_search_call records, capturing the raw generated arguments.
2. logs_2.sqlite, table codex_core::tools::router: Log entries with the error failed to parse tool_search arguments....
3. logs_2.sqlite, table codex_client::transport: Raw POST JSON payloads sent to /v1/responses, which map input[28] and input[62] to their corresponding response items.

Confirmed locally with additional evidence.

Root cause appears to be mixed-format historical replay:

• some persisted tool_search_call items store arguments as a JSON string
• replay path later sends that value back to the Responses API without coercing it to an object
• the Responses API then rejects input[n].arguments for tool_search_call with invalid_type

We verified a narrow local fix in codex-rs:

1. On deserialize/read of ResponseItem::ToolSearchCall, if arguments is a stringified JSON object, parse it into a JSON object.
2. In prompt/history normalization before replay, coerce any in-memory legacy stringified tool_search_call arguments into objects as a defensive fallback.

This dual-layer fix is idempotent and fail-closed:

• valid objects stay unchanged
• only stringified JSON objects are coerced
• invalid or non-object strings are left untouched rather than guessed

Relevant local patch points:

• protocol/src/models.rs: ToolSearchCall arguments deserialization
• core/src/context_manager/normalize.rs: prompt replay normalization

Also added regression coverage for:

• deserializing stringified tool_search_call arguments
• history normalization before prompt replay