multi_agent_v2: OpenAI parent → custom-provider subagent starts correctly but receives an empty task payload

What issue are you seeing?

What version of Codex is running?

Codex Desktop / codex-cli 0.146.0-alpha.9.2

Platform

Windows, Codex Desktop

Models and providers

• Parent agent: OpenAI-backed model
• Custom subagent:
• provider: deepseek
• model: deepseek-v4-flash
• wire API: responses
• endpoint: https://api.deepseek.com/

Summary

When an OpenAI-backed parent agent spawns a custom subagent using a non-OpenAI
provider, the child session is created with the correct provider and model, but
the delegated task payload is not available to the child model.

The child receives the inter-agent message header, but the actual task content
appears only as encrypted_content. The custom-provider model behaves as if the
payload were empty.

Minimal provider configuration

[model_providers.deepseek]
name = "DeepSeek"
base_url = "https://api.deepseek.com/"
wire_api = "responses"
env_key = "DEEPSEEK_API_KEY"

What steps can reproduce the bug?

1. Start Codex Desktop with an OpenAI-backed parent model.

1. Configure a custom subagent using:

• model_provider = "deepseek"
• model = "deepseek-v4-flash"
• wire_api = "responses"

1. Verify that the DeepSeek provider works through a direct request.

1. Ask the parent agent to spawn deepseek_worker with a concrete assignment:

Reply with exactly: DEEPSEEK_TASK_OK

1. Inspect the spawned child session.

The child session is created successfully and its metadata correctly shows
model_provider = "deepseek" and model = "deepseek-v4-flash".

However, the child does not receive the delegated task. It behaves as if the
payload were empty and responds with something similar to:

Standing by for task assignment.

Sending a follow-up message to the same child produces the same result.

What is the expected behavior?

The custom-provider child should receive the complete delegated task as usable plaintext input and reply:

DEEPSEEK_TASK_OK

When the parent and child use different providers, Codex should convert the inter-agent task into a provider-neutral representation. Provider-specific encrypted_content generated in the OpenAI parent context should not be the only representation of the task available to the custom-provider child.

Additional information

Environment:

• Codex Desktop
• codex-cli: 0.146.0-alpha.9.2
• Parent: OpenAI-backed model
• Child role: custom deepseek_worker
• Child provider: deepseek
• Child model: deepseek-v4-flash
• DeepSeek endpoint: https://api.deepseek.com/
• Wire API: responses
• Platform: Windows

The child rollout contains an inter-agent event whose plaintext header ends with an empty payload:

Message Type: NEW_TASK
...
Payload:

The actual task appears in a separate encrypted content item:

{
  "type": "encrypted_content",
  "encrypted_content": "gAAAAA...REDACTED..."
}

Control tests:

1. An OpenAI-backed child receives the same assignment and returns the expected marker.
2. The DeepSeek child completes the assignment when it reads the same task from a temporary plaintext file.
3. DeepSeek authentication, Responses API access, model selection, tool calls, and workspace access therefore appear to work correctly.

This suggests that the failure is isolated to native cross-provider inter-agent message delivery. One possible cause is that provider-specific encrypted content from the OpenAI parent is retained without converting the delegated task to portable plaintext before constructing the custom-provider request.

The local rollout confirms that the child does not receive usable task text. It does not establish whether the encrypted item is forwarded to DeepSeek or filtered while Codex builds the provider request.

Related issues:

• #17598
• #17541
• #33267

A plaintext file mailbox currently works as a temporary workaround, but it bypasses native agent messaging and is not suitable as a permanent solution.

I can provide sanitized parent and child rollout excerpts if required. I have not attached the complete rollout files because they contain local paths, workspace context, and other session instructions.