[Bug] AskUserQuestion cancelled by the user must hard-stop the agent: cancel is an unambiguous "premise rejected" signal, not a plain tool result #1384

Summary

When the user cancels/declines an AskUserQuestion dialog, the harness returns the cancellation to the model as an ordinary tool result and the agent remains free to keep executing tools in the same turn. A cancellation must instead be treated as a hard stop: no further actions until the user's next explicit message.

Observed behavior (repro)

1. The agent asks the user a question via the AskUserQuestion dialog.
2. The user cancels the dialog — picks no option, uses no "Other" input.
3. The agent receives "the question was declined" as a regular result and continues working in the same turn.
4. In the concrete incident (ZCode Desktop, Windows 11, 2026-11-03): the question was "what to do with GitHub repositories the agent had created"; the user cancelled the dialog; the agent immediately proceeded to run further commands against those very repositories (gh repo edit --visibility private, gh api .../collaborators).

The model was under explicit instructions to stop on cancellation and still did not — see "Why this must be harness-level" below.

Expected behavior: user's model of the dialog semantics

The dialog UI already provides a dedicated control for every user intent:

Because every "continue"-type intent already has its own dedicated control, the meaning of Cancel is fully determined by elimination — and it is not ambiguous:

Cancel = "none of the answers fits; the premise of the question itself does not satisfy the user; the user owes no answer."
The agent must stop — and then figure out why it asked such a question at all (its premise was wrong), because the user should never be forced to answer a question whose premise is broken.

So a cancellation is not "no preference" and not "pick a safe default". It is a rejection of the question's premise, i.e. a stop signal plus a demand to re-examine why the question arose.

Requested behavior

On cancellation the harness must:

1. Suspend the agent's turn — block all further tool calls until the user's next explicit message. A hard, harness-level guarantee, not a model-side convention.
2. Deliver the cancellation to the model as a directive, not soft context, e.g.:
   USER DECLINED THE QUESTION — STOP. Do not act. Await the user's next message.
3. Convey the premise-rejection semantics, e.g. "the premise of your question was rejected — be prepared to explain why you asked".

Why this must be enforced by the harness, not by the model

Soft context does not work. In the observed incident the model, despite explicit instructions, reinterpreted the decline as "no preference — act on a safe default" and continued acting. Interpretation of an ambiguous-looking signal is precisely what a model cannot be relied upon for here; the harness is the right place to make Cancel non-negotiable. The current design treats a cancel as mere information ("the question was declined") with no state change — no pause, no gate — which makes the correct behavior model-dependent and, as demonstrated, unreliable.