[xAI/Grok Responses] V2 child result agent_message causes parent HTTP 422 #3907

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/responses

The 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:

• https://docs.x.ai/developers/tools/function-calling
• https://docs.x.ai/developers/model-capabilities/text/comparison

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:

1. Apply only on translated/strict xAI Responses dispatch, not canonical ChatGPT forwarding.
2. Recognize only a structurally complete plaintext agent_message with representable content.
3. Convert the readable content to an ordinary user message, optionally retaining non-sensitive author/recipient attribution in text.
4. Keep encrypted-only, empty, or malformed items fail-closed.
5. 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:

• fix(opencode-go): lower Codex-private input items Console Go rejects #3838: provider-specific lowering of Codex-private agent_message items for another strict Responses endpoint.
• [Responses] Codex task-input envelopes are rejected by translated adapters #3735: external Codex task-input envelope lowering for translated adapters.
• [Bug] V2 custom-parent → custom-child delegation needs current-dev trace #418: routed/custom parent-to-child V2 completion tracing.
• V2 cross-provider sub-agent loses NEW_TASK body in encrypted_content #92: native-parent to routed-child encrypted 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

• I searched existing provider and compatibility issues.
• The request and response were redacted.
• The expected behaviour is based on an upstream specification or a concrete client requirement.