[Regression] Mixed encrypted agent_message history bypasses routed Responses fail-closed #4454

Client or integration

Codex App / Codex CLI

Provider or upstream service

xAI OAuth / Grok 4.6

OpenCodex version

@bitkyc08/opencodex 2.52.0

Endpoint or capability

POST /v1/responses; routed Responses adapter and multi-agent history replay

Current behaviour

OpenCodex 2.52.0 can forward a historical agent_message item to a non-forward Responses destination when the item contains mixed readable and backend-encrypted content. xAI/Grok rejects the request with HTTP 422:

Failed to deserialize the JSON body into the target type:
input[5]: 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

The child work and initial routed requests can succeed. After a sub-agent result is recorded in the parent history, later requests repeatedly fail at the upstream schema boundary. The failing input index changes as the history grows (input[5], input[8], and so on).

The local usage log contains 60 recent xai/grok-4.6 HTTP 422 records and 55 HTTP 200 records. All 422 records select provider=xai, model=grok-4.6, requestedModel=xai/grok-4.6, inboundProtocol=responses, routeKind=explicit-provider. No request body or ciphertext is included here.

A failing historical item has this redacted shape:

{
  "type": "agent_message",
  "author": "/root/child",
  "recipient": "/root",
  "content": [
    { "type": "input_text", "text": "visible child result or routing text" },
    { "type": "encrypted_content", "encrypted_content": "<backend ciphertext redacted>" }
  ]
}

The item is not necessarily the last element of input; it can be followed by later user messages and tool items. Metadata-only inspection of response-state spill files around the failures confirmed content part types input_text + encrypted_content.

Expected behaviour

For a non-forward Responses destination, no private agent_message item with unsupported content should be sent upstream.

If a historical encrypted result cannot be safely recovered, OpenCodex should fail closed before provider dispatch with a structured error and must not echo or log the ciphertext. Plaintext agent-message conversion, native ChatGPT forward passthrough, and the current encrypted NEW_TASK trust/recovery boundaries should remain unchanged.

Minimal redacted request or reproduction

1. Start a fresh Codex App task using xai/grok-4.6 with the V2 collaboration surface.
2. Let a sub-agent run and return a result.
3. Continue the parent task so the result is replayed in the next /v1/responses request.
4. Observe HTTP 422 with unknown item type agent_message.
5. Inspect only item metadata and confirm a non-tail agent_message with content part types input_text + encrypted_content.

The local proxy endpoint shown to the client is http://127.0.0.1:10100/v1/responses. The upstream xAI destination and all credentials are omitted.

Actual response or error

HTTP 422 Unprocessable Entity
unexpected status 422 Unprocessable Entity:
Failed to deserialize the JSON body into the target type:
input[5]: unknown item type "agent_message"

Upstream documentation

xAI documents standard Responses input and tool-result items, but does not document Codex's private agent_message item type:

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

The expected behaviour is also a concrete Codex client requirement: a routed parent must be able to consume a completed child result without sending a provider-private item.

Suggested mapping or implementation notes

The current path is:

1. src/adapters/openai-responses.ts calls normalizeRoutedAgentMessages() for every non-forward provider.
2. src/adapters/routed-agent-messages.ts rewrites an agent_message only when every content part is input_text, input_image, or input_file. If encrypted_content or an unknown part is present, it returns the original private item unchanged by design.
3. src/server/responses/encrypted-payload.ts hasUnreadableEncryptedAgentTask() inspects only the trailing agent_message. This protects the current NEW_TASK envelope but intentionally ignores historical agent messages.
4. src/server/responses/core.ts computes the unreadable-task flag before expandPreviousResponseInput() and before the later sanitization step. A historical item inserted/replayed later, or any non-tail item, can therefore reach the adapter with unreadableEncryptedAgentTask=false.
5. The adapter serializes the unchanged agent_message and strict xAI Responses validation returns HTTP 422 instead of a bounded OpenCodex error.

This is a coverage gap after #3907/#3911, which fixed complete readable agent_message conversion. #92 and #3661 cover encrypted NEW_TASK delivery/recovery, not historical child-result replay.

A narrow fix would add a shared routed-replay classification after expandPreviousResponseInput() and before adapter dispatch:

• Fully representable plaintext agent_message: use the existing public message conversion.
• Current unreadable encrypted NEW_TASK: keep the existing recovery/fail-closed path.
• Historical or mixed encrypted agent_message: detect explicitly. The safe default is a bounded structured failure (for example, a distinct historical_encrypted_agent_message reason) rather than a provider-specific 422. If maintainers choose an opt-in lossy compatibility mode, retain visible plaintext parts, replace encrypted parts with a fixed placeholder, and then lower the item to a public message; never attempt transparent decryption of historical child results.

Add a regression test with a mixed agent_message in a non-tail position after expandPreviousResponseInput(). Assert that no private agent_message reaches a routed Responses adapter, and that either a public message is emitted or the structured fail-closed error is returned. Keep authMode=forward and complete plaintext messages unchanged. Ensure ciphertext is not logged, cached as plaintext, or returned to the client.

An adjacent edge is also visible in the current helper: an empty agent_message (content: []) is returned unchanged and can still produce the same upstream 422.

Additional context and attachments

Related issues:

• [xAI/Grok Responses] V2 child result agent_message causes parent HTTP 422 #3907 — plaintext xAI/Grok child-result agent_message 422 (closed; plaintext normalization landed)
• Routed Responses destinations 422 on Codex agent_message items replayed from sub-agent history #3911 — routed Responses agent_message 422 (closed; generalized plaintext normalization landed)
• V2 cross-provider sub-agent loses NEW_TASK body in encrypted_content #92 — upstream native-to-routed encrypted NEW_TASK limitation (closed as upstream tracking)
• unreadable_encrypted_agent_task intermittently fails routed V2 subagent dispatch (strict recovery envelope; no retry during chatgpt.com 5xx windows) #3661 — intermittent encrypted V2 task recovery gaps (open; different dispatch/recovery boundary)
• Multi-Agent V2 sends OpenAI-specific agent_message items to external Responses providers openai/codex#33551 — Multi-Agent V2 sends private agent_message items to external Responses providers

This report is narrower than #3907/#3911: it covers encrypted mixed historical replay that still bypasses the fail-closed guard after those fixes.

The Codex runtime selected by ocx doctor is 0.151.0; 0.154.0-alpha.6.2 is also present on the host. This version mismatch is recorded for context, but the 422 is directly correlated with the mixed content shape and the adapter branch above.

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.