Sub-agent task payload still dropped for custom providers on codex-cli 0.154.0 (Windows, Responses-profile) — silent no-op

Environment

• codex-cli 0.154.0 (npm install), Windows 11 x64, interactive TUI (originator: codex-tui)
• custom model provider profile, launched with -p <profile> (model_provider: deepseek, wire_api = "responses", model deepseek-flash)
• Related existing reports: #36586, #37237, #37822, #36321, #36376. This issue adds a confirmation on 0.154.0 stable (earlier reports were on 0.145.0 / 0.146.x / 0.147.0-alpha) plus a verified workaround.

What happens

spawn_agent returns success ({"task_name":"/root/<name>"}), the child thread starts a turn, but the task body never reaches it. In the child rollout the task item is persisted as:

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

The child model only receives the envelope (Payload: with nothing after it) plus an opaque encrypted_content block, so it replies that it received no task.

Evidence

• 3 children were spawned (source.subagent.thread_spawn, depth: 1); in each child rollout the only user item is the <recommended_plugins> environment block — no user/agent message carries the task text.
• 3/3 children replied "no task content received" (verbatim, independently).
• followup_task retries (3 messages) and a one-line probe produced the same envelope shape.
• Two wait_agent calls timed out (300 s and 420 s).
• spawn_agent never returned an error, so the parent kept waiting for agents that could not act.

Expected

• The spawn task and any followup_task payload should be presented to the child as readable message text.
• A delivery failure should surface as an error (or the spawn should ack only after the payload is visible to the child).

Impact

Silent failure for any custom (non-OpenAI Responses) provider: multi-agent verification/parallel auditing is unusable, and the failure is only visible by inspecting child rollouts (~12 minutes lost in our run before falling back).

Workaround (verified on the same machine, same profile)

Running a real separate process works:
codex exec -p <profile> "…" → exit 0, correct reply, new session id (01a09b34-…, 16.9 s wall). Independent processes are a usable substitute for sub-agent fan-out, and would be worth documenting in the multi-agent docs while this is unresolved.

Reproduce the issue with codex-cli 0.154.0 on Windows using the custom Responses profile, then inspect the spawn_agent and followup_task paths and the child rollout payload. Compare the envelope and encrypted_content behavior with the working separate-process codex exec workaround. Done means task text is readable by the child and delivery failures surface instead of silently waiting.