Comment added when answering a subagent-raised permission prompt appears to go to the subagent, not the main agent

Summary

When a subagent (spawned via the Task/Agent tool) raises a permission prompt, and I answer it with an added comment (the "Yes, and here's more context" / "No, and tell Claude what to do differently" free-text field), that comment appears to be delivered into the subagent's context rather than the main agent's. The subagent then treats my text as instructions from its orchestrator, does something off-target, and returns a result the main agent didn't ask for.

Because the prompt UI gives no indication of which agent raised the request (see #91368 — subagent prompts are distinguished only by color), I can't tell at answer-time whether my comment will reach the main agent or a subagent. So the same keystroke means different things depending on who happens to be asking, and I only discover the difference after a subagent has gone sideways.

What I expected

Answering a permission prompt is a decision about that specific action. A comment I add is steering, and I expect steering to reach the main agent — the one I'm actually in a conversation with — regardless of which agent's tool call triggered the prompt. At minimum, if the comment is going to a subagent, the prompt should say so.

What actually happens

• Main-session prompt + comment → comment reaches the main agent (works as I'd expect).
• Subagent-raised prompt + comment → comment appears to be consumed by the subagent. The subagent's returned result reflects my comment as if it were an instruction from the orchestrator, and diverges from what the main agent had delegated.

Steps to reproduce

1. In a session, have the main agent spawn a subagent via the Task/Agent tool to do some scoped work.
2. Arrange for the subagent to hit a tool call that requires permission (e.g. a web fetch or a shell command not pre-approved).
3. When the permission prompt appears, choose "Yes" (or "No") and type additional context into the comment field — phrase it as guidance you intend for the main agent.
4. Observe the subagent's returned result: it reflects the typed comment as if directed at the subagent, and comes back off-target from what the main agent delegated.

Notes / uncertainty

I'm reporting this as an observed behavior, not a confirmed mechanism — I haven't instrumented where the comment is routed, only seen the downstream effect repeatedly. Two related data points:

• #91368 confirms subagent-originated prompts are differentiated (only) by color, so there's no non-color signal of which agent is asking.
• A comment on #23983 (from disassembling the 2.1.207 bundle) notes that an in-process teammate resolves its own permission dialog via its own ToolUseContext.requestDialog, i.e. subagents handle permission dialogs in their own context — which is at least consistent with the comment being delivered there.

Whether this is a bug or working-as-coded, the user-facing problem is the same: there is no reliable, predictable way to attach steering to a permission answer and know it will reach the main agent, and no indication of which agent I'm answering.

Possible resolutions (not prescriptive)

• Route permission-answer comments to the main agent regardless of which agent raised the prompt; or
• Clearly label subagent-raised prompts (text, not color) so the user knows the comment's destination before submitting (overlaps with #91368); or
• Document the current routing explicitly so the behavior is at least predictable.

Related

• #91368 — subagent permission prompts distinguished only by color (the "which agent is asking?" gap)
• #23983 — PermissionRequest hooks not firing for subagent permission requests (adjacent permission-plumbing issue)

Environment

• Claude Code version: observed circa v2.1.239; still present as of v2.1.267
• OS: Linux

<hr>
This issue was generated by Claude Opus 4.8 under my guidance.