Repository navigation
Sub-agent task payload still dropped for custom providers on codex-cli 0.154.0 (Windows, Responses-profile) — silent no-op #45233
Description
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", modeldeepseek-flash) - Related existing reports: Subagent task payload invisible to custom non-OpenAI providers (DeepSeek): encrypted_content block dropped with multi_agent_version v2 #36586,
spawn_agentsilently creates empty sub-agents for any non-OpenAI Responses provider — task body sent asencrypted_contentand dropped, with zero diagnostics #37237, spawn_agent / followup_task message payload never reaches the sub-agent (encrypted_content is dropped) #37822, [Bug] spawn_agent/followup_task/send_message: child agents receive empty task payload (multi-agent v2, 0.146.0-alpha.9.2) #36321,0.147.0-alpha.4: OpenAI parent still sends encrypted V2 task to non-OpenAI child after #35845 #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_taskretries (3 messages) and a one-line probe produced the same envelope shape.- Two
wait_agentcalls timed out (300 s and 420 s). spawn_agentnever returned an error, so the parent kept waiting for agents that could not act.
Expected
- The spawn task and any
followup_taskpayload 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.
Activity
dajiaohuang commentedon Sep 13, 2026
The 0.154.0 custom-provider reproductions show spawn_agent succeeds while the child receives only an empty Payload plus encrypted_content; a separate codex exec process works. Could maintainers confirm whether encrypted_content is expected to be decoded by the child runtime and which public transport boundary owns the fix? That determines whether a focused CLI or app-server patch is safe.
ZhiHanyu-H57 commentedon Sep 22, 2026
Confirmation on Codex Desktop 26.915.31945 / codex-cli 0.155.0-alpha.9.2 (Windows) + one extra observation
Reproduced again on a newer build. Version data point plus a recursion detail that I did not see covered above.
Environment
26.915.31945, bundledcodex-cli 0.155.0-alpha.9.2, Windows 11 / PowerShellmodel = "deepseek-flash",model_provider = "deepseek"[model_providers.deepseek]:base_url = "https://api.deepseek.com/",wire_api = "responses"Probe 1 —
fork_turns="none"spawn_agent(task_name="probe_none_delivery", message="Reply with exactly: DELIVERY-NONE-OK", fork_turns="none"){"task_name":"/root/probe_none_delivery"}, no error.Note: on this run the
<recipient>/<author>placeholders were not substituted in the child's rendering.Probe 2 — control with
fork_turns="all"Same message with a full-history fork: the child likewise reported an empty payload and did not act on the message text.
Extra observation — the failure is recursive
In probe 2 the child spawned its own sub-agent (
/root/probe_all_control/delivery_probe), and that grandchild also reported receiving no task body. So the broken delivery is not limited to depth 1; it propagates down the spawned tree.Impact in this session
Three spawn attempts, zero usable child outputs.
spawn_agentreported success each time and the parent sat waiting on agents that had nothing to do, until the child reports were inspected manually. Local mitigation: dispatch background work to an independent Codex process instead ofspawn_agent(same shape as thecodex execworkaround noted in this thread).Related: #36586 (code-level root cause + validated
"multi_agent_version": "v1"workaround), #37237, #37822, #36321, #36493, and #46939 (config request for plaintext delivery).(The reproduction above was executed automatically by Codex running in that environment; the quoted child output is the child agent's own report.)