Subagent task payload invisible to custom non-OpenAI providers (DeepSeek): encrypted_content block dropped with multi_agent_version v2

[qum1nzhennan]

Summary

When using a custom non-OpenAI provider (DeepSeek) with Codex multi-agent (subagents), tasks
dispatched via spawn_agent / followup_task are never seen by the subagent. The subagent
initializes, reads the workspace, and then replies that it has no task input ("no new task
input"), so every subagent run is a no-op.

Environment

• Codex CLI 0.145.0 on Windows
• Custom provider in config.toml: [model_providers.deepseek] with
  base_url = "https://api.deepseek.com/" and wire_api = "responses"
• model = "deepseek-v4-flash", model_catalog_json = "~/.codex/models.json" (written by the
  official DeepSeek one-command setup, which sets "multi_agent_version": "v2" in both entries)
• Multi-agent tools: collaboration__spawn_agent / followup_task (MultiAgentV2 tool surface)

Reproduction

1. Start a session with deepseek-v4-flash (models.json entry has
   "multi_agent_version": "v2").
2. Spawn a subagent with a simple task, e.g. "reply exactly: PONG".
3. The subagent replies with a workspace status summary and asks what to work on; it never
   executes the dispatched task. followup_task with the same prompt also yields
   "no new task input".

Same setup with a native catalog model (e.g. gpt-5.6-sol) executes subagent tasks correctly.

Root cause

For MultiAgentV2, the task payload is always delivered through an
InterAgentCommunication::new_encrypted(..) record whose content is a
[input_text header, encrypted_content] pair:

• codex-rs/core/src/tools/handlers/multi_agents_v2.rs — communication_from_tool_message
  uses new_encrypted(author, recipient, vec![], message, trigger_turn) for every
  non-DirectPlaintextMessage source, so the task text lives in the encrypted_content
  content block.
• codex-rs/core/src/client.rs — in build_responses_request, the !is_openai branch only
  clears FunctionCall.encrypted_function_args; it does not handle
  ResponseItem::AgentMessage content, so the encrypted_content block is sent to the
  provider API unchanged.
• codex-rs/core/src/client_common.rs — get_formatted_input_for_request passes the items
  through as-is.

For OpenAI endpoints the agent-message payload is decrypted/rendered server-side, which is why
native models work. The DeepSeek Responses API does not understand the encrypted_content
content block type and drops it, so the model only receives
Message Type: NEW_TASK\nTask name: ...\nSender: ...\nPayload: with an empty payload.

Workaround (validated)

Set "multi_agent_version": "v1" for the custom model entries in ~/.codex/models.json
(instead of "v2"). With V1 the spawn initial input is delivered as a plain user message
(SpawnInitialInput::UserInput) instead of an inter-agent communication, and DeepSeek
subagents execute tasks correctly (verified with a codex exec spawn test returning the
expected output). Restart the session after editing models.json.

Note: this means custom non-OpenAI models cannot currently use the MultiAgentV2 tool surface
at all.

Suggested fix

In build_responses_request (codex-rs/core/src/client.rs), extend the !is_openai branch
to transform ResponseItem::AgentMessage content: fold the encrypted_content block into a
single InputText (header text + payload), mirroring the plaintext rendering already used by
communication_from_tool_message's DirectPlaintextMessage path. This lets custom
wire_api = "responses" providers receive subagent task payloads while keeping V2 behavior.

Related

• MCP tools silently unavailable with DeepSeek official setup (custom models.json: supports_search_tool=true + tool_mode=null) #36382 — MCP tools silently unavailable with DeepSeek official setup (same family:
  custom models.json + non-OpenAI provider gaps in tool/content handling)

[github-actions]

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

• Sub-agent task messages are delivered with an empty payload (Codex Desktop) #36493
• multi_agent_v2: OpenAI parent → custom-provider subagent starts correctly but receives an empty task payload #36387
• 0.147.0-alpha.4: OpenAI parent still sends encrypted V2 task to non-OpenAI child after #35845 #36376

Powered by Codex Action

[CCanxue]

Additional reproduction and a working local patch (codex-cli 0.146.0 source, deepseek-v4-flash, wire_api = "responses", multi_agent_version = "v2").

Wire-level finding: even when the agent_message content is rewritten so the payload is plaintext input_text (no encrypted_content), DeepSeek still ignores the agent_message item in most runs and the child replies that it has no task. The task is only consumed reliably when it is delivered as a plain user message.

Working local patch: for non-OpenAI providers, deliver V2 spawn / followup_task / send_message payloads as plain user input (UserInput), mirroring the V1 SpawnInitialInput::UserInput path. The OpenAI path keeps encrypted InterAgentCommunication unchanged. Verified end-to-end with the real provider: spawn_agent -> PONG, followup_task -> PONG2.

The multi_agent_version: "v1" workaround does not work with deepseek-v4-flash: with DeepSeek's catalog (supports_search_tool: true), the V1 tool family is registered as Deferred behind tool_search. The tool_search tool is present in the request tools array, but deepseek-v4-flash does not recognize or call it (same family as #36382), so the V1 tools are unreachable and v1 stays broken for this model.

Full patch, build/install steps, QA evidence and config templates (sanitized) are published here: https://github.com/CCanxue/codex-deepseek-subagent-fix

[liushiyao110]

Reproducing on Codex Desktop (macOS), app version 26.727.51351, with deepseek-v4-flash via the official one-command DeepSeek setup (wire_api = "responses", multi_agent_version: "v2" in models.json).

Both spawn_agent (initial task) and followup_task fail the same way: the child initializes, reads the workspace, then replies "I don't see a task in this message yet" / "Ready when you are — just send over the task."

Log evidence (rollout JSONL): the delivered agent_message contains an input_text envelope with an empty Payload: plus an encrypted_content block holding the actual task. The HTTP request POSTed to https://api.deepseek.com/responses carries that encrypted_content block untouched, so DeepSeek only sees the empty envelope. Normal user messages are plain input_text and work fine in the same session.

This confirms the issue is not CLI-only — it also affects the Desktop app with a non-OpenAI model as the root agent. Happy to provide full rollout logs or test a proposed fix.

[trillox9]

Same issue on codex-cli 0.146.0 with the official DeepSeek setup

Environment:

• codex-cli 0.146.0 on Windows 11 (PowerShell)
• model: deepseek-v4-flash
• Provider configured exactly as in the official DeepSeek guide:
  wire_api = "responses", base_url = "https://api.deepseek.com/",
  model_catalog_json with multi_agent_version = "v2"

Reproduction:

1. The main agent calls collaboration__spawn_agent with a concrete task
   (e.g. "run Get-Date and return the output").
2. The child agent starts, but instead of executing the task it replies
   with a generic greeting: "I'm ready to help. What would you like me to
   work on?"
3. followup_task has the same behavior: the child keeps greeting and never
   receives/executes the follow-up.
4. With fork_turns="all", the child receives no task at all and instead
   replays the parent's spawn calls from the inherited context, creating
   recursive spawn chains (I had to interrupt them manually).

What I found in the logs:

• The POST to https://api.deepseek.com/responses contains the task as an
  input item of type "agent_message", with the real payload inside
  "encrypted_content". The visible content stops at "Payload:" with an
  empty text.
• DeepSeek's Responses API compatibility table only supports these input
  item types: message, function_call, function_call_output, reasoning,
  web_search_call. It explicitly says other types are ignored.
• As a result, the model never sees the task and just greets the user.

Expected behavior:

• For non-OpenAI providers, subagent tasks should be delivered as a plain
  user message (like the community patch does), or Codex should fail fast
  with a clear "provider does not support agent_message input items"
  error instead of silently dropping the task.

Happy to provide redacted request/response logs or test a patched build.