[FEATURE] Machine-readable AskUserQuestion state and no-answer semantics

Preflight Checklist

• [x] I have searched existing enhancement requests for "AskUserQuestion unattended marker timeout no-answer semantic answer" and did not find this targeted request.
• [x] This is a single feature request.

Problem Statement

Claude Code's interactive AskUserQuestion / question UI is useful when a human is present, but it currently creates unsafe ambiguity for unattended or multi-session operation.

When the harness asks a question during an autonomous run, operators and coordinating agents need to distinguish several states that currently blur together:

• The session is still working.
• The session is blocked on a question and needs a human.
• The question timed out or should be treated as "no answer".
• A coordinating agent has enough durable authority to answer semantically.

Without a machine-detectable question marker and no-answer path, downstream automation has to infer state from terminal text or keystrokes. That is fragile and can produce two bad incident classes:

1. A "phantom answer" class, where generic text injection or recovery keystrokes accidentally select an option in an interactive question.
2. An all-night freeze class, where an unattended run is blocked on a question but external coordination cannot reliably tell that the session is waiting for user input rather than working.

This is a harness/runtime concern rather than something project tooling can safely solve. In ADT we intentionally rejected an ADT-side keystroke "answer" implementation because it would rebuild the phantom-answer failure class.

Proposed Solution

Expose AskUserQuestion as a first-class, machine-readable interaction state with safe unattended semantics:

1. A machine-detectable marker when a session is blocked on AskUserQuestion, including a stable question id, question text, option ids/labels, and whether an unattended answer is allowed.
2. A timeout or operator-configurable policy that can resolve to an explicit "no answer" sentinel without choosing one of the visible options.
3. A gated semantic answer channel that accepts a structured answer by question id, not raw keystrokes, and only when the harness has exposed that the question is answerable by automation.
4. A way for external/session-management tooling to observe the state without screen-scraping the TUI.

The key safety property is that unattended tooling can report or park a question without accidentally selecting an answer, and any automated answer is bound to the specific question id/options the harness exposed.

Alternative Solutions

Current workarounds are all weaker:

• Terminal screen scraping can guess that a question is visible, but it is brittle across UI changes.
• Raw tmux/keyboard injection can answer the wrong prompt or select an option accidentally.
• Esc-cancel recovery can sometimes unwind a stuck session, but it is a recovery path, not a semantic answer API.
• Project-level coordination tools can record decisions, but they cannot prove the harness is currently asking a specific question with specific options.

Priority

High - Significant impact on productivity

Feature Category

Interactive mode (TUI)

Use Case Example

1. A hub/coordinator starts several Claude Code workers overnight.
2. One worker reaches an AskUserQuestion prompt about whether to proceed with a scoped operation.
3. The coordinator queries session state and sees a structured blocked_on_question object with question id, text, options, and timeout/no-answer policy.
4. If the coordinator lacks authority, it parks the decision and reports "worker blocked on question X" without selecting anything.
5. If durable policy allows a semantic answer, the coordinator sends a structured answer for that question id.
6. If no answer arrives before the timeout, the harness emits an explicit no-answer sentinel rather than silently choosing a default.

Additional Context

This request comes from the ADT hub control-plane work. The hub design explicitly treats a semantic AskUserQuestion answer API as upstream-only because project tooling cannot safely implement it with keystrokes.

Related design note in ADT: docs/dev/2026-06-24-hub-program-control-plane-plan.md, section 9 ("Hard / upstream").