Summary

On POST /provider/v1/responses, the input item that carries a Codex multi-agent v2 subagent's task reaches the child model without its task: the child sees the environment/context but not the assignment, so Codex subagents routed to Command Code models answer with things like "What would you like me to work on?" instead of performing the task. The same conversations complete correctly when translated to chat completions, and multi-agent v1 (plain-text task delivery) works on /responses — so the gap is specific to how /responses renders v2 child turns.

Expected Behavior

A Codex child turn's first request contains the collaboration task envelope as an input item:

{"type":"agent_message","author":"/root","recipient":"/root/pong_task","content":[
  {"type":"input_text","text":"Message Type: NEW_TASK\nTask name: /root/pong_task\nSender: /root\nPayload:\n"},
  {"type":"encrypted_content","text":""}
]}

The model should receive its task in a form it can act on (the envelope item and/or the replayed parent history that carries the task), like it does when the same input goes through /provider/v1/chat/completions.

Actual Behavior

The child model never sees its task. Observed across multiple runs, with two different parent kinds (a GPT parent — gpt-6.1-sol with the Codex client's plaintext-v2 delivery — and a meta/muse-spark-1.3-contributor parent), always with deepseek/deepseek-v4.1-flash as the child on /responses:

• The child's final answer asks what to work on — e.g. "What would you like me to work on? Share the task, and I'll pull in the relevant Superpowers skills as required and get started."
• In other runs the child wanders (reading unrelated local context) and its final message is leaked DSML tool-call markup emitted as plain text instead of a structured function_call.
• Single-model sessions and plain user-message turns on /responses work fine (streaming, reasoning summaries, structured tool calls) — only the v2 child-turn shape loses the task.

Steps to reproduce the issue

1. Use a Codex client (App or CLI) with multi-agent v2 and Command Code configured as the model provider for a subagent (e.g. child model deepseek/deepseek-v4.1-flash via https://api.commandcode.ai/provider/v1).
2. In a parent session, ask: "Spawn a subagent using the model deepseek/deepseek-v4.1-flash that replies with exactly PONG. Wait for it to finish, then report only its answer."
3. The child runs (requests hit /responses, tokens are consumed) but responds as if no task was delivered (asks for a task / wanders), instead of answering PONG.
4. Control A — route the same child model through a chat-completions translation of the identical input: the child completes and answers PONG.
5. Control B — switch the parent to multi-agent v1 (plain-text task delivery): the child on /responses completes and answers PONG.

So the failing combination is specifically: v2 child turn + native /responses.

Command Code Version

Provider API consumer (not the CLI): hitting https://api.commandcode.ai/provider/v1/responses directly, GOAT plan. Reproduced 2026-10-01, multiple runs ~18:15–19:00 UTC.

Operating System

macOS client / Linux server — protocol-level issue, OS-independent.

Terminal/IDE

Codex App/CLI (openai/codex, rust client with multi-agent v2), early-October 2026 builds, routed through our own load balancer.

Shell

n/a

Session file (optional)

n/a — the envelope JSON above is the relevant request shape; full request/response captures (JSONL rollouts and network captures) available on request.

Fix prompt (optional)

In the /responses request pipeline, check how input items of type agent_message (Codex collaboration envelopes with author/recipient fields and content parts of type input_text + encrypted_content) and the replayed parent history items are rendered into the upstream prompt. Today the task carried by the v2 envelope is effectively dropped for these models: whatever path converts Responses input items into the upstream request needs to preserve/present the envelope's text (and the parent-history items that carry the assignment) so the child model can read it — the chat-completions path on the same gateway already does this correctly, and v1-shaped plain-text tasks already survive /responses. Verify with: a child-turn request containing the envelope above against deepseek should produce a model response that references/uses the task, not "no task received".

Additional context

• Parent-kind independence: reproduced with a GPT parent (gpt-6.1-sol) and with a muse parent — the constant is the v2 child shape on /responses.
• With the task delivered through chat completions (or v1), the same parent→child flow answers PONG reliably, which is how we run Command Code models as Codex subagents today.
• Fixing this would let native /responses consumers use Codex multi-agent v2 with Command Code models as subagents without a chat-completions translation layer in between.