AskUserQuestion answers invisible to auto-mode permission classifier — destructive calls re-blocked after explicit consent

Summary

When AskUserQuestion is used as a consent gate before a destructive action and the user picks an affirmative option, the follow-up Bash call is denied by the auto-mode permission classifier with a message along the lines of "the user's answer to the AskUserQuestion is not visible in the transcript so explicit consent for X is not established". The classifier does not appear to read AUQ answers when evaluating whether the user authorized the next action.

Repro

1. Agent emits AskUserQuestion with options describing the exact action it's about to take (e.g. "push to a public remote", "delete resource X", "merge to shared branch"). Options something like "Yes — proceed" / "No — abort".
2. User clicks the affirmative option.
3. Agent issues the corresponding Bash command.
4. Auto-mode classifier denies the call, citing missing explicit consent.

Resulting UX

The agent often interprets the denial as "user wasn't clear" and re-asks the same question with more detail. The user answers again. The classifier denies again. Loop, until either:

• the user types prose consent into chat (which the classifier does read), or
• the agent gives up and prints the command for the user to run themselves.

From the user's side the agent looks like it's asking the same question repeatedly for no reason. Skill authors who design flows around \"AUQ for explicit confirmation before destructive Bash\" find their flows looping with no path forward without manual workarounds.

Expected

A user clicking an affirmative option in AskUserQuestion should count as the same level of explicit consent as a typed chat message of equivalent content, for tool calls within the same turn that match the AUQ's described action.

Suggested fix

Include the most recent resolved AskUserQuestion answers in the input the auto-mode classifier sees when deciding \"did the user authorize this action?\".

Alternatively (worse UX): document that AUQ cannot serve as a consent gate for destructive Bash and recommend skill authors print commands for the user to run instead — but this defeats the AUQ UX entirely.