Client or integration
Codex App
Provider or upstream service
xAI OAuth / Grok 4.6
OpenCodex version
2.46.0 (also reproduced on 2.43.0)
Endpoint or capability
POST /v1/responses, MultiAgentV2, routed-parent child-result delivery
Current behaviour
A Codex App task using xai/grok-4.6 as the V2 parent can spawn and run xai/grok-4.6 children successfully. The failure begins when the first child completes and Codex appends the child result to the parent history as a plaintext agent_message input item.
The next parent request is routed correctly to xAI/Grok, but the strict Responses endpoint rejects the whole request with HTTP 422 because agent_message is not in its accepted input-item union. Codex retries the same incompatible request and the parent turn ends in systemError.
This reproduced twice on Ubuntu 24.04 with Codex CLI/App Server 0.153.4:
- OpenCodex 2.43.0: first returned child result was followed immediately by repeated 422 errors at
input[134].
- OpenCodex 2.46.0: 248 requests completed with HTTP 200; the first child then completed, one plaintext
agent_message was recorded in the parent rollout, and six consecutive parent requests failed with HTTP 422 at input[69].
The child itself completed normally. The failure boundary is child-result delivery to the routed parent, not child creation, model routing, rate limiting, or encrypted NEW_TASK delivery.
As a control, the same workload on the V1 surface did not emit this agent_message failure and did not produce the 422 class.
Expected behaviour
For a translated/strict xAI Responses destination, OpenCodex should lower a complete readable plaintext Codex agent_message into a wire-safe ordinary user message before dispatch, so the routed parent can consume the child result and continue orchestration.
Encrypted-only or malformed agent messages should remain fail-closed. Native ChatGPT passthrough, genuine tool-result items, and unrelated Responses input types should remain unchanged.
Minimal redacted request or reproduction
# Configuration shape
# - OpenCodex 2.46.0
# - Codex 0.153.4
# - multiAgentMode: v2
# - xAI OAuth provider
# - parent model: xai/grok-4.6
# - child models: xai/grok-4.6
1. Start a fresh Codex App task on xai/grok-4.6 with the V2 collaboration surface.
2. Ask the parent to spawn multiple xai/grok-4.6 workers, wait for them, and aggregate their returned results.
3. Observe that child requests execute successfully.
4. Wait for the first child to complete.
5. Confirm that the parent rollout receives an item shaped as:
{
"type": "agent_message",
"id": "amsg_<redacted>",
"author": "/root/<redacted-worker>",
"recipient": "/root",
"content": "<non-empty plaintext child result>"
}
6. The immediately following parent request to /v1/responses returns HTTP 422.The production reproduction used ten workers, but the first completed worker was sufficient to trigger the failure; no 422 occurred before the first agent_message arrived.
Actual response or error
unexpected status 422 Unprocessable Entity: {
"error": "Failed to deserialize the JSON body into the target type: input[69]: unknown item type \"agent_message\"; expected one of: message, reasoning, function_call, function_call_output, shell_call, shell_call_output, web_search_call, file_search_call, code_interpreter_call, mcp_call, custom_tool_call, image_generation_call, compaction"
}, url: http://127.0.0.1:10100/v1/responsesThe earlier 2.43.0 reproduction reported the same error at input[134].
Upstream documentation
xAI documents ordinary Responses inputs and tool-result continuation using message and function_call_output; it does not document Codex-private agent_message items:
There is no public xAI specification for Codex App's private inter-agent input envelope. The expected behaviour is based on the concrete Codex client requirement that a routed parent receive a completed child's plaintext result.
Suggested mapping or implementation notes
This appears similar in failure class to #3838, where a strict translated Responses endpoint rejects Codex-private agent_message items and a provider-scoped lowering converts readable content to a user message.
Suggested narrow boundary:
- Apply only on translated/strict xAI Responses dispatch, not canonical ChatGPT forwarding.
- Recognize only a structurally complete plaintext
agent_message with representable content.
- Convert the readable content to an ordinary user
message, optionally retaining non-sensitive author/recipient attribution in text.
- Keep encrypted-only, empty, or malformed items fail-closed.
- Add a regression covering routed Grok parent -> routed Grok child -> child completion -> parent continuation.
The existing common parser already maps agent_message to a user-role context message, but the observed xAI Responses outbound request still carries the raw private item, suggesting the passthrough/raw-body lane bypasses that parsed representation.
Additional context and attachments
Related but distinct:
No research content, filesystem paths, credentials, account identifiers, request authorization, full child output, or unredacted payloads are included.
Checks
Client or integration
Codex App
Provider or upstream service
xAI OAuth / Grok 4.6
OpenCodex version
2.46.0 (also reproduced on 2.43.0)
Endpoint or capability
POST /v1/responses, MultiAgentV2, routed-parent child-result deliveryCurrent behaviour
A Codex App task using
xai/grok-4.6as the V2 parent can spawn and runxai/grok-4.6children successfully. The failure begins when the first child completes and Codex appends the child result to the parent history as a plaintextagent_messageinput item.The next parent request is routed correctly to xAI/Grok, but the strict Responses endpoint rejects the whole request with HTTP 422 because
agent_messageis not in its accepted input-item union. Codex retries the same incompatible request and the parent turn ends insystemError.This reproduced twice on Ubuntu 24.04 with Codex CLI/App Server 0.153.4:
input[134].agent_messagewas recorded in the parent rollout, and six consecutive parent requests failed with HTTP 422 atinput[69].The child itself completed normally. The failure boundary is child-result delivery to the routed parent, not child creation, model routing, rate limiting, or encrypted
NEW_TASKdelivery.As a control, the same workload on the V1 surface did not emit this
agent_messagefailure and did not produce the 422 class.Expected behaviour
For a translated/strict xAI Responses destination, OpenCodex should lower a complete readable plaintext Codex
agent_messageinto a wire-safe ordinary usermessagebefore dispatch, so the routed parent can consume the child result and continue orchestration.Encrypted-only or malformed agent messages should remain fail-closed. Native ChatGPT passthrough, genuine tool-result items, and unrelated Responses input types should remain unchanged.
Minimal redacted request or reproduction
The production reproduction used ten workers, but the first completed worker was sufficient to trigger the failure; no 422 occurred before the first
agent_messagearrived.Actual response or error
unexpected status 422 Unprocessable Entity: { "error": "Failed to deserialize the JSON body into the target type: input[69]: unknown item type \"agent_message\"; expected one of: message, reasoning, function_call, function_call_output, shell_call, shell_call_output, web_search_call, file_search_call, code_interpreter_call, mcp_call, custom_tool_call, image_generation_call, compaction" }, url: http://127.0.0.1:10100/v1/responsesThe earlier 2.43.0 reproduction reported the same error at
input[134].Upstream documentation
xAI documents ordinary Responses inputs and tool-result continuation using
messageandfunction_call_output; it does not document Codex-privateagent_messageitems:There is no public xAI specification for Codex App's private inter-agent input envelope. The expected behaviour is based on the concrete Codex client requirement that a routed parent receive a completed child's plaintext result.
Suggested mapping or implementation notes
This appears similar in failure class to #3838, where a strict translated Responses endpoint rejects Codex-private
agent_messageitems and a provider-scoped lowering converts readable content to a user message.Suggested narrow boundary:
agent_messagewith representable content.message, optionally retaining non-sensitive author/recipient attribution in text.The existing common parser already maps
agent_messageto a user-role context message, but the observed xAI Responses outbound request still carries the raw private item, suggesting the passthrough/raw-body lane bypasses that parsed representation.Additional context and attachments
Related but distinct:
agent_messageitems for another strict Responses endpoint.NEW_TASK; this report is the opposite direction and the returned child result is readable plaintext.No research content, filesystem paths, credentials, account identifiers, request authorization, full child output, or unredacted payloads are included.
Checks