Claude threads have no async question: a pending AskUserQuestion holds the thread's scheduled tasks, PR wakes and child results until the person answers #164

What happens

A Claude thread asks the person with AskUserQuestion. Lazurio's agents do this on purpose: root decision 0211 of HumanAndMachines/Lazurio wants questions to go through the tool, so the person gets a notification.

For Claude the question is synchronous:

• ClaudeAdapterV2.ts creates the user_input request with responseCapability: { type: "live" };
• the provider's turn waits on a Deferred until the answer comes (ClaudeAdapterV2.ts:6882, :9318, at v0.1.3-lazurio.1).

Since #139, every message that arrives meanwhile waits in the queue behind that turn, so that it cannot cancel the question (#119). That is right for the question. The cost is that the whole thread stops for the person:

• the thread's own scheduled tasks;
• PR watch notices;
• delegated-task completions;
• messages from other threads.

Observed, 2026-10-31 to 11-01. One Claude thread on a Mac with T3 Code 0.1.3 asked a question at 23:17Z. The person answered at 08:27Z the next morning. Meanwhile 11 runs waited in its queue:

• the thread's own scheduled task, due at 07:10Z;
• one run with four delegated-task completions;
• nine PR watch notices.

The scheduled task happened to be harmless that day. On 10-31 a similar question had already cost a time-bound window, because the thread could not act on its own background watcher.

So an agent with a schedule has two bad options. It can ask in plain text, which gives no notification, the thing 0211 wants to avoid. Or it can use the tool and risk missing its own wake.

What T3 Code already has

Codex threads already have async questions:

• an agentMessage with delivery: "async" and questions becomes a user_input request with responseCapability: { type: "message" } (CodexAdapterV2.ts:4958);
• the agent keeps working;
• the answer arrives later as the user message async-answer:<requestId> (Orchestrator.ts:8148), which steers the active run or starts a new one.

Upstream T3 Code describes the same feature in pingdotgg#15258, pingdotgg#15873 and pingdotgg#24914. All three are about Codex.

Claude has only the synchronous AskUserQuestion. The release notes of upstream v0.1.6 and of the 0.1.7 nightlies up to 2026-11-01 mention no async path for it:

• v0.1.6's side chats are questions the person asks;
• "Questions move threads out of Working" (fix(clients): questions always move a thread out of Working pingdotgg/t3code#28515) is about thread status.

Expected

An agent of any provider, Claude included, can ask the person a question that does not hold its thread.

• The person sees the same question card and gets the same notification as for AskUserQuestion: header, options, multi-select and free text.
• The agent's turn can end right after asking.
• Queued messages, scheduled tasks and child results run as usual while the question waits.
• The answer arrives later as async-answer:<requestId>, exactly like Codex's async answers today, and starts a run if the thread is idle.

Suggested shape

• One T3 MCP tool for every provider, with the AskUserQuestion input schema (questions, options, multiSelect):
  • it creates a user_input request with responseCapability: { type: "message" } on the calling thread;
  • it returns the requestId at once;
  • it reuses the existing async-answer dispatch. No second question model.
• Existing tools stay as they are: t3_pending_request and t3 request list, read and answer these requests like Codex's.
• The tool description tells the agent when to use it. Ask async when the agent has scheduled tasks, delegated children or PR watches, or when the person is likely away. Ask synchronously only when the agent must not go on without the answer.

Tests

• A Claude thread asks through the tool.
  • The request is pending with responseCapability.type == "message", the turn ends and the thread is idle.
  • A queued message and a scheduled task both run while the question waits.
  • The answer arrives as async-answer:<requestId> and starts a run that begins with the answer.
• Display. The question card, the notification and the pending-question indicator behave as for Codex's async questions.
• With steer as the default (v0.1.3), any steer must queue while the turn waits on a pending question or approval #139's guard is unchanged for the synchronous AskUserQuestion.

After this lands

Root decision 0211 in HumanAndMachines/Lazurio can then say that agents ask through the async tool by default. Until then, agents with a schedule ask in text when a wake is due before the person will likely answer.

Requested by Matěj (Organization Admin), 2026-11-01: T3 Code should give agents asynchronous questions, so that a question never blocks scheduled work.

Agent: environment 0f732f59-9f07-474d-abcb-2149bb79f9d5 · T3 thread 996ea181-b716-4e78-8940-a048b7c5d4c4