Multi-agent subagent notifications leak into the main chat as raw JSON assistant messages
What version of Codex CLI is running?
codex-cli 0.120.0
What subscription do you have?
Pro
Which model were you using?
gpt-5.4
What platform is your computer?
Darwin 24.6.0 arm64 arm
What terminal emulator and version are you using (if applicable)?
Ghostty
What issue are you seeing?
Subagent completion/mailbox traffic is leaking into the main chat transcript as raw JSON assistant messages. This message leak also causes agent turn to end and wait for user input.
Example of what shows up in the main chat:
{"author":"/root/task1_spec_review_rerun","recipient":"/root","other_recipients":[],"content":<subagent_notification>\n{\"agent_path\":\"/root/task1_spec_review_rerun\",\"status\":{\"completed\":\"SPEC_PASS ...\"}}\n</subagent_notification>","trigger_turn":false}
What steps can reproduce the bug?
This appears when using subagents, but not always. Latest release made it much more frequent.
Here is a session where this behaviour appeared multiple times:
thread ID 019d8094-a19c-7372-8e3c-a61a44ad4571
What is the expected behavior?
Multi-agent workflows should continue to work, but internal subagent notifications / mailbox messages should not be rendered into the main user-facing chat as raw JSON.
Additional information
This looks like a regression.
There appear to be two relevant changes:
- 773fbf56a4 on 2026-03-24, feat: communication pattern v2 (#15647)
- This appears to be the bug-enabling change.
- Subagent completion notices that were previously hidden user-fragment notifications started being sent on the MultiAgentV2 path as InterAgentCommunication assistant envelopes.
- e4f1b3a65 on 2026-04-03, Preempt mailbox mail after reasoning/commentary items (#16725)
- This appears to be the recent change that made the problem much more visible/frequent.
- It preempts for pending mailbox mail after reasoning/commentary items, which seems to surface these assistant envelopes much more often.
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
This is a subtle but impactful bug — subagent internal communication leaking into the main chat as raw JSON is not just a UX issue, it actively corrupts the conversation context.
The most dangerous aspect: the raw JSON is interpreted as an assistant message. If the model in a subsequent turn tries to "continue" from that leaked JSON, it may treat the subagent's internal state as established context and make decisions based on data that was never meant for the main conversation. We have seen similar cross-contamination patterns where an AI agent in one working directory picks up context from an unrelated session and generates code for the wrong project.
The fact that this also causes the agent turn to end and wait for user input is particularly problematic for autonomous workflows — the agent stops mid-task, the user has to intervene, and the intervention itself becomes additional context that can further confuse the conversation state.
This is structurally similar to the "stdout pollution" problem in CLI tools where debug/logging output gets mixed into structured JSON responses. The downstream parser (or in this case, the conversation manager) cannot distinguish between intentional output and leaked internal traffic.
For anyone dealing with multi-agent workflows where context isolation matters, we have found it helpful to add explicit boundary checks that verify the conversation context has not been corrupted by cross-agent traffic. Essentially a "context integrity" check at each turn boundary.
npx @opencodereview/cli scan . --sla L1
Multi-agent v2 is not meant to be used right now. Models are not trained yet to use it. But none of these are bugs. This design is built on purpose for the new models
Are you enabling the feature ? Can you /feedback and give me the session ID please?
I saw this behaviour before I switched to v2, but they got more frequent after switching to v2 for sure. Actually it was Codex's recommendation to try v2.
I will disable v2 and try again. If i see the same issue, I'll share the session id here.