You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Multi-agent subagent notifications leak into the main chat as raw JSON assistant messages #17523
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.
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.
Subagent completion notices that were previously hidden user-fragment notifications started being sent on the MultiAgentV2 path as InterAgentCommunication assistant envelopes.
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.
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.
Activity
github-actions commentedon Apr 12, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
raye-deng commentedon Apr 12, 2026
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
jif-oai commentedon Apr 13, 2026
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?
ozan-s commentedon Apr 13, 2026
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.