`spawn_agent` silently creates empty sub-agents for any non-OpenAI Responses provider — task body sent as `encrypted_content` and dropped, with zero diagnostics

Summary

The ChatGPT desktop app's embedded Codex runtime (cli 0.147.0-alpha.1.2, app 26.730.61639) creates sub-agents via spawn_agent / followup_task, but when model_provider points at a non-OpenAI Responses-compatible endpoint (wire_api="responses" -> e.g. https://api.deepseek.com), the task body never reaches the sub-agent. The sub-agent spawns, sees only an empty "Message Type: NEW_TASK ... Payload:" header, and replies "I don't see a specific task." Switching model_provider to the OpenAI backend makes it work. No error is surfaced anywhere. This silently breaks the multi-agent feature for every third-party provider.

Repro

config.toml:

model = "deepseek-v4-flash"
model_provider = "deepseek"

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

In a session:

1. spawn_agent(task_name="test", message="Reply with DELIVERY_OK only", fork_turns="none")
2. wait_agent
3. list_agents

Observed: spawn_agent returns {"task_name": "/root/test"} (success). But list_agents shows the sub-agent completed with "Hi! It looks like your message may not have come through yet — I don't see a specific request to work on."

Root cause — captured from the wire

The HTTP request the app sends to the third-party endpoint serializes the task as:

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

The encrypted_content content item is forwarded verbatim. A third-party Responses endpoint has no way to render that type, so the body is dropped and the model only sees the empty Payload: header. The same spawn under model_provider="openai" resolves correctly.

Notes:

• This is not a tool-contract problem: spawn_agent's task_name / message / fork_turns arguments are exactly as documented, and the handler returns a valid task path.
• followup_task (target + message) fails the same way; its output is silently empty.
• fork_turns="all" partially masks it: the child gets the parent's forked history, but still not the per-agent spawn message. fork_turns="none" yields a fully empty agent.

Suspected area: the multi-agent v2 delivery path (core/src/tools/handlers/multi_agents_v2/spawn_agent.rs, followup_task.rs) and core/src/agent_communication.rs, where inter-agent messages are stored/transported as encrypted_content items and only expanded on the OpenAI backend.

Expected behavior

• encrypted_content in agent-message payloads must be decrypted/expanded to plaintext input_text before the request is serialized to any provider; or
• if that expansion is intentionally OpenAI-only, spawn_agent / followup_task must fail loudly with a clear error instead of silently spawning an empty agent.

Silently creating a sub-agent with no task — and silently returning empty results for followup_task / send_message — is the worst possible failure mode: no exception, no log, just empty agents doing nothing.

Environment

• macOS (Darwin 25.5.0)
• ChatGPT desktop app 26.730.61639 (build 6234), embedded Codex runtime cli 0.147.0-alpha.1.2
• model=deepseek-v4-flash, model_provider=deepseek, base_url=https://api.deepseek.com, wire_api=responses