[FEATURE] AskUserQuestion tool result cannot be distinguished from a genuine human response

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When a subagent session calls the AskUserQuestion tool, the tool's return value has the same format regardless of whether a human actually saw and clicked an option, or whether the answer was auto-returned without any human interaction (e.g. under a bypass-permissions-style mode).

Return format observed:
"Your questions have been answered: "<question>"="<selected label>" selected"

In our case, a subagent running inside an isolated worktree called AskUserQuestion twice for real approval decisions (whether to proceed with implementation, whether a UI line could be deleted). Both times the tool returned a result with the "(recommended)" labeled option selected, while no human had actually seen or interacted with the question. The subagent had no way to tell, from the tool result alone, whether this was a real human answer or an automatic one.

This is a trust/safety-relevant gap: any workflow that treats AskUserQuestion results as a human approval gate (e.g. "proceed only after user confirms") cannot currently verify that a human was actually involved.

Proposed Solution

Have the AskUserQuestion tool result (or an adjacent signal available to the calling agent) indicate whether the answer came from an actual UI interaction versus an automatic/bypassed path. For example, an explicit field like "source": "human" | "auto" alongside the selected answer, so agents can distinguish real approval from auto-approval before treating it as authorization for consequential actions (implementation, commit, push, deletion, etc.).

Alternative Solutions

Currently the only workaround we found is: after receiving an AskUserQuestion result from a subagent, have the parent/coordinating session (or a human) independently re-confirm with the actual user whether they were really shown and answered the question. This is manual, easy to forget, and only discovered after the fact in our case.

Priority

High - Significant impact on productivity

Feature Category

API and model interactions

Use Case Example

1. A parent Claude Code session delegates a task to a subagent session running in an isolated worktree (e.g. via Orca-style multi-session orchestration), possibly in a permission mode that can auto-approve some actions.
2. The subagent calls AskUserQuestion for a real decision (e.g. "should I proceed with this implementation?").
3. The subagent receives a result in the normal format: "Your questions have been answered: "<question>"="<label>" selected".
4. The subagent has no way to tell whether a human actually saw and clicked that option, or whether the answer was returned automatically without any human involved.
5. The subagent (reasonably) treats this as a real human approval and proceeds with consequential actions (implementation, commit, push).
6. It later turns out no human was ever shown the question.

Additional Context

_No response_