Orchestrator has no visibility when a user injects messages directly into a dispatched subagent's conversation
Title
Orchestrator has no visibility when a user injects messages directly into a dispatched subagent's conversation
Summary
Claude Code lets a user join and send messages directly into a background subagent's live conversation while it's running. That's a useful capability. But the orchestrator (main) conversation that dispatched the subagent has no way to know this happened. The orchestrator only sees the subagent's final summary/result -- not that the user steered it mid-task -- so any deviation between what the orchestrator asked for and what the subagent actually did looks, from the orchestrator's side, like the subagent went off-script or made a mistake.
Steps to reproduce
- In a main conversation, dispatch a background subagent with explicit, narrow instructions -- e.g. "write a one-paragraph product description for a coffee mug, nothing else."
- While the subagent is running, open its conversation directly and send it an additional instruction the orchestrator never asked for -- e.g. "also add a tagline at the end."
- Let the subagent finish and return its result to the main conversation.
Expected behavior
The main conversation's task-notification (or some accessible field) indicates that the user intervened directly in the subagent's conversation, ideally including what was added, so the orchestrator can attribute the deviation correctly.
Actual behavior
The orchestrator only receives the subagent's final output. It has no signal that a human (rather than the subagent's own reasoning) introduced the extra instruction. The orchestrator therefore reports the tagline as an unrequested addition or a possible mistake by the subagent, when in fact it was an authorized user instruction the orchestrator simply could not see.
Impact
In any workflow where an orchestrator dispatches subagents and later reasons about whether their output matches the dispatch instructions (review loops, audit trails, "did the agent do what I asked"), user-injected mid-task instructions are systematically misclassified as agent deviation. This produces incorrect commentary back to the user and forces the user to manually clarify, every time, that a given difference was their own doing.
Suggested fix
Surface user-originated messages sent into a subagent's conversation back to the orchestrator -- e.g. as part of the task-notification payload, or as an annotated entry in the subagent's transcript that's distinguishable from the subagent's own tool calls/output. Even a simple boolean/flag ("user sent N messages directly to this subagent during the run") would let the orchestrator avoid mischaracterizing the result.