spawn_agent / followup_task message payload never reaches the sub-agent (encrypted_content is dropped)

What version of the Codex App are you using (From “About Codex” dialog)?

26.803.41515（build 6321

What subscription do you have?

N/A (using API key / custom provider)

What platform is your computer?

Darwin 25.6.0 arm64 arm

What issue are you seeing?

When the root agent calls spawn_agent or followup_task, the sub-agent is created and its turn is triggered, but the
message payload never appears in the sub-agent's context. The sub-agent only sees system-level content (skills
instructions, permissions, AGENTS.md, environment context) and replies with a generic "waiting for task" message.

The framework constructs the inter-agent communication object with an empty content field and stores the payload
exclusively in encrypted_content. The receiving side builds its turn input from content only
(user_input_count=0) and never decrypts/consumes encrypted_content; no decryption error is logged, so the payload
is silently dropped.

Reproduced on the Codex desktop app 26.803.41515 and in a fresh codex exec CLI process (0.147.0-alpha.6.5), with
both fork_turns=none and fork_turns=all. Full reproduction steps, raw log evidence, and a downloadable evidence
archive (bug-evidence.zip) are in the report below.

What steps can reproduce the bug?

Minimal reproduction (desktop app):

1. In any project directory, open Codex (ChatGPT desktop app).
2. From the root agent, run:
   spawn_agent(task_name="ping", message="Reply with exactly: PONG", fork_turns="none")
3. Wait for the spawned agent's turn to complete.
4. Actual result: the sub-agent replies with a generic "waiting for task" message
   (e.g. "已就绪，等待任务内容。请把要处理的写作任务发给我…") instead of "PONG".

Follow-up reproduction (same session):

5. Run: followup_task(target="ping", message="Reply with exactly: PONG")
6. Actual result: the follow-up turn again completes with a generic
   "waiting for task" reply; the message text never reaches the sub-agent.

CLI reproduction (fresh process):

7. Run:
   /Applications/ChatGPT.app/Contents/Resources/codex exec --json --skip-git-repo-check
   "用 spawn_agent 派生一个子 agent（task_name=cli_ping, fork_turns=none, message='Reply with exactly: PONG'），等待
   它回复，然后原样报告它第一条回复的文本。如果 spawn_agent 工具不可用或派生失败，明确说明原因。"
8. Actual result: the CLI spawns the sub-agent successfully, but the sub-agent
   explicitly reports that its turn input contained no task text (it even waited
   15s on the mailbox with no queued message).

Expected result in all cases: the sub-agent's first reply is exactly "PONG".

What is the expected behavior?

When the root agent calls spawn_agent, the spawned sub-agent's first turn should contain the message text as a user
input, so the sub-agent can see and execute the task.

When the root agent calls followup_task, the message should appear in the target agent's next turn.

More generally: the payload should not be silently dropped. If encryption of the message is required but decryption on
the receiving side is not possible, the framework should surface an explicit error instead of delivering a turn with
empty input.

Additional information

A few things that should make this easier to triage:

1. Evidence archive: bug-evidence.zip is attached to this issue. It contains verbatim (raw, unmodified) log extracts,
   not paraphrases — sender-side tool calls, the framework's InterAgentCommunication records, the sub-agent's session
   messages, the receiver's user_input_count=0 turn logs, and the CLI reproduction. The report's "Log evidence" section
   maps each file to its excerpt.

2. The failure has been reproduced continuously since 2026-08-09 across multiple sessions, in both the desktop app and
   the bundled CLI, with fork_turns=none, fork_turns=all, spawn and follow-up. It is not configuration- or
   fork_turns-related.

3. The wake-up path works: the sub-agent is created, its turn is triggered, and SubAgentActivity /
   inter_agent_communication dispatch are logged normally. Only the payload delivery is broken.

4. Direction asymmetry: sub-agent → root replies use plaintext content and are delivered; only root → sub-agent task
   messages fail (they are stored in encrypted_content with empty content and never rendered into the model turn).

5. No decryption error is ever logged — the encrypted_content payload is never consumed, which suggests a missing/
   not-wired decryption step on the receiving side (or the sender should populate content for same-host communication).

6. Local config experiment already performed: adding [features.multi_agent_v2] wait_agent_enabled = true and
   retesting in a fresh codex exec process did not change the behavior; the config was rolled back.

7. Impact: any workflow that delegates work via spawn_agent / followup_task is unusable. Real-world case: an 8-agent
   writing pipeline (awesome-novel, .codex/agents/*.toml + order-file protocol) blocks at the first spawn_agent because
   the sub-agent never receives the order path. With fork_turns="all", sub-agents silently replay the parent's history
   instead, which can cause unintended actions.

Start at the spawn_agent and followup_task entry points and trace the inter-agent communication path from the sender to the receiving turn. Reproduce the issue using the supplied desktop or CLI steps and inspect why encrypted_content is not consumed when content is empty. Done means the task message reaches the sub-agent, or an explicit decryption or delivery error is surfaced.