Feature request: async AskUserQuestion — queue new forms behind the active one

Resolved 💬 1 comment Opened Apr 23, 2026 by 0xnfrith Closed May 27, 2026

Summary

When an agent invokes AskUserQuestion while the operator still has a previous form open, the second call blocks at the tool layer and the agent sits idle until the first form is answered. Propose making AskUserQuestion async by queueing subsequent forms behind the active one (FIFO). The agent's turn completes immediately on submission; the operator sees the next form only when they dismiss the current one.

Problem

Today's blocking behavior costs two things at once:

  1. Agent idle time. The agent's tool call hangs until the user answers. Any parallel work it wanted to do (more tools, more reasoning, writing to disk) stalls behind the form.
  2. Expressive floor. The tool is effectively restricted to \"ask one question at a time that gates the next step.\" Streams of information — research notes, decision summaries, SDR drafts, screenshot-backed context packages — have to go into the transcript as scrollable text, because sending them as a sequence of AskUserQuestion forms would serialize the agent behind every \"Proceed\".

Proposal

Make AskUserQuestion submissions non-blocking:

  • Every call goes onto a per-session FIFO queue.
  • The operator sees one form at a time. Answering/dismissing the current form pops the next queued form into view.
  • The agent's tool call returns immediately with a queued or accepted ack — the operator's answer arrives later as a separate inbound signal (same way tool results land today, just decoupled from send-time).

Knobs

  • collapse_if_duplicate: true — if a queued form has the same question text as one already in the queue, merge it instead of adding another entry. Prevents a runaway loop from flooding the operator with 40 identical prompts.
  • Allow single-option forms. The schema today enforces a minimum of 2 options. For the \"long question, only action is Proceed\" pattern (which this feature enables), a single option (or zero, i.e. acknowledge-and-dismiss) is the natural shape. The screenshot below had to include a filler second option (\"Dismiss\") just to satisfy the schema — that's a visible footgun.

Use cases unlocked

  • Streaming read-only context. Subagent collects 5 pieces of research evidence, sends each as a long-text Proceed form. Operator reads them at their own pace; main agent keeps working.
  • Non-blocking acknowledgments. Agent posts \"Dashboard is up at http://127.0.0.1:4646\" as a dismissible form instead of a transcript line the user has to scroll back to find.
  • Decision summaries before big actions. Agent drafts a destructive-action summary as a form with \"Confirm / Cancel\" — but the agent continues with low-risk work until the operator answers.

Demo / character-ceiling test

Screenshot below is from a current-gen AskUserQuestion with ~1,800 chars in the question field. Renders cleanly without truncation (the 6 sentences the test prompt asked for all display). This is a data point for how much content a single form can carry today — useful for sizing the streaming-context use case above.

!Async AskUserQuestion demo

Environment

  • Claude Code Desktop, Thu Apr 23 2026
  • Opus 4.7 (1M context)
  • macOS arm64

Priority notes

Async behaviour is the headline ask. The collapse_if_duplicate knob and single-option relaxation are two smaller quality-of-life items that naturally pair with it — none are blocking each other.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗