[Bug] spawn_agent/followup_task/send_message: child agents receive empty task payload (multi-agent v2, 0.146.0-alpha.9.2)

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #35932

Powered by Codex Action

Reproduced on stable 0.146.0 as well (DeepSeek, wire_api = "responses", multi_agent_version = "v2"), covering all three tools: spawn_agent, followup_task and send_message.

Wire-level detail: the request does contain the NEW_TASK envelope, but Payload: is empty because the task text sits in encrypted_content; DeepSeek drops that block. Even a plaintext input_text inside the agent_message item is ignored by DeepSeek in most runs. Delivering the same text as a plain user message works reliably.

Local patch + build/install guide: https://github.com/CCanxue/codex-deepseek-subagent-fix

I hit a related MultiAgentV2 / spawn_agent failure today in Codex Desktop while trying to orchestrate a small multi-agent workflow.

This may not be the exact same encrypted-payload failure described in the issue body, but it looks adjacent because the root agent could not get a valid spawn_agent call through the tool boundary at all.

Environment observed from this machine:

• PATH codex: codex-cli 0.146.0
• ChatGPT/Codex Desktop embedded CLI: codex-cli 0.146.0-alpha.9.2
• Provider: OpenAI / ChatGPT-auth Codex Desktop session
• Native subagent tool exposed in the session as spawn_agent

What happened:

The model-visible tool shape exposed both message and items as callable fields, with guidance saying to use either message or items. In practice, attempted calls repeatedly failed with:

Provide either message or items, but not both

The failure happened because empty/default fields still counted as present. For example, calls shaped like this failed:

{
  "fork_context": true,
  "items": [],
  "message": "...task text...",
  "model": "gpt-5.6-terra",
  "reasoning_effort": "medium",
  "service_tier": "priority"
}

And the inverse shape with items: [...] plus message: "" also failed. From the public source, this lines up with parse_collab_input(message, items) treating (Some(_), Some(_)) as invalid, without normalizing empty items or an empty default message as absent.

Why this matters:

If the client/tool schema makes both branches appear present, or if the tool wrapper materializes the unused branch as an empty array/string, the root agent has no reliable schema-valid way to spawn a child agent. The delegation fails before we can even observe whether the child receives the payload. In my case, a harness agent that was supposed to delegate design, implementation, and QA subtasks degraded back to single-threaded local work.

Expected behavior:

One of these would make the tool much more robust:

1. The model-visible schema should express message vs items as a real oneOf / mutually exclusive choice, where the unused branch can be omitted entirely.
2. The tool binding should not auto-materialize the unused branch as items: [] or message: "".
3. The parser could defensively treat an empty unused branch as absent when the other branch is non-empty, e.g. items: [] + non-empty message should behave as message-only.
4. The error message could include the exact valid call shape, because the current schema/guidance makes it easy for the root agent to retry the same invalid shape.

Again, this is not necessarily the same child-side empty-payload bug, but it seems like the same broader MultiAgentV2 spawn_agent tool-surface problem: schema/default payload shape and runtime validation are not aligned, so subagent orchestration can fail even when the parent agent is explicitly trying to use the native tool correctly.

This looks like a separate tool-surface bug from the empty-payload issue tracked here: the failure happens before delivery, in the message vs items validation (parse_collab_input rejecting both being present, including empty defaults). Worth filing as its own issue so maintainers can track the schema/validation mismatch separately. I agree that treating an empty unused branch as absent (option 3) is the smallest robust fix.

Root cause
MultiAgentV2 delivers tasks through InterAgentCommunication: the plaintext content is empty, and the entire task text is placed in the encrypted_content content block. OpenAI endpoints decrypt and render this block server-side, which is why native models work; DeepSeek's Responses implementation does not recognize encrypted_content (community packet captures show that sending a request containing this content item directly returns a 400 / it gets dropped), so the sub-agent only sees an empty Payload:. This is the same family of issues as openai/codex #36493, #36321, #36586, #37237, and #37822.
Verified workaround (currently in effect on this machine)
Modify both entries in ~/.codex/models.json:

• "multi_agent_version": "v2"
• "multi_agent_version": "v1"
• "supports_search_tool": true
• "supports_search_tool": false

Rationale: supports_search_tool=false makes search_tool_enabled=false, so deferred tools are no longer hidden behind tool_search but are exposed directly to the model (the same mechanism as the workaround in #36382). The v1 tool family then becomes directly visible, and v1 delivers tasks as plain user messages (UserInput), which DeepSeek consumes reliably.