[Feature]: Let agents ask the user via the t3-code MCP server (t3_pending_request_create)

[FelipeAvella]

Problem

Agents without a native ask-the-user tool can't reach T3's structured question card.

Claude Code gets it via AskUserQuestion (claudeUserInputQuestions in ClaudeAdapterV2), Codex via requestUserInput and async questions, OpenCode via its question tool, and ACP agents via form elicitation (AcpAdapterV2). Pi has no native equivalent. The only path a Pi extension has into T3 is extension_ui_request, and PiAdapterV2 maps every select / input / editor dialog to exactly one question:

questions: [piQuestion(nativeRequestId, method, title, event)],

Pi's RPC dialog carries only title, options: string[], and timeout, so an extension can't express several questions, per-option descriptions, or multi-select. As far as I can tell, CursorAdapterV2 has no user-input path either.

What already exists

• The t3-code MCP server already has t3_pending_request_list / _read / _respond, which let an agent see and answer pending user questions. Nothing lets an agent create one.
• V2 already supports non-blocking questions: CodexAdapterV2 emits async questions as a user_input_request with responseCapability: { type: "message" }, and Orchestrator delivers the answers as the next user message (async-answer:<requestId>), steering a running turn or resuming an idle session.
• McpInvocationScope already carries threadId, providerSessionId, and capabilities, so a tool call knows where to show the card and can be gated per provider.
• Agent-facing thread tools are already the direction: t3_thread_update ([Feature]: Let the agent update its thread title once the work is actually decided #7333) is on the V2 branch.

Proposal

Add t3_pending_request_create to the t3-code MCP server:

• Input: an array of the existing OrchestrationV2UserInputQuestion (id, header, question, options[{ label, description }], multiSelect, allowCustomAnswer, required).
• Behavior: create a user_input_request in the calling thread with responseCapability: { type: "message" } and return immediately, telling the agent to end its turn. The answers then arrive through the same async-answer path Codex already uses.
• Scope: expose it only to providers without a native question tool, currently Pi and possibly Cursor, so models don't see two ways to ask.

Why non-blocking

A tool that blocks until the user answers doesn't fit the Pi bridge. piT3McpExtensionSource sends tools/call as a plain fetch with only the turn's abort signal, and Node's built-in fetch (undici) defaults to 300 s header and body timeouts, so a question left unanswered for more than five minutes would fail. Blocking also wouldn't survive a server restart. The message capability avoids both, lets the user answer later from mobile, and matches the t3_thread_wait pattern of not holding calls open.

Alternatives considered

• Pi-only adapter convention: PiAdapterV2 already special-cases the subagent tool by name. A similar convention for questions would help only Pi and would still need a way to wait for the answer.
• Pi through ACP elicitation: multi-question works there, but it loses the native Pi integration: rollback, resume, thinking levels, context meter, and permission modes.

Current workaround

A Pi extension asks each question in turn with ctx.ui.select outside the TUI. It prefixes the title with [1/2 · Label] and puts option descriptions into the option strings. It works, but each question is a separate card, the title shows twice (the card header and body both come from title), and there's no multi-select.

Environment

T3 Code 0.0.43-preview.20260925.2234 (V2 preview), Pi 0.87.1, Node 22 (undici 6.24), server on Linux (WSL2), clients on web and desktop.

[kvnloo]

One invariant I'd add before implementing this is idempotent request creation.

t3_pending_request_create could accept a stable clientRequestId and return the created requestId, so a retry after disconnect/restart can't create duplicate question cards.

I'd also bind the request to the originating provider session / turn generation. If that generation has been replaced before the answer arrives, the answer should become stale-but-visible rather than silently steering the newer turn.

That would make the non-blocking approach safe across the restart/reconnect failures it's intended to survive.

[BenWortley]

A use case beyond Pi. We have Claude agents end their turn with AskUserQuestion, so threads waiting on the user don't auto-settle. Two gaps remain:

• Claude questions are live (responseCapability: { type: "live" } in ClaudeAdapterV2, still on main @ 9bd1d80). A server update closes the session and cancels them. On 4 Oct an update cancelled a question that had waited 8 hours, and the thread auto-settled 24 minutes later. Nightlies land about twice a day here, so overnight questions are at risk.
• Codex in Default mode can't use request_user_input, so Codex agents can only ask in plain text, which doesn't block settlement.

A question with message response capability, created through the MCP server, would cover both. It survives the session closing and works for any provider.

[denis229115]

Another use case, for orchestrator threads. A Claude orchestrator delegates work with delegate_task (mode: "async") and ends its turn. When a child's result arrives, the orchestrator often needs a decision from me: merge, revise, or drop it, or which of two approaches to take. Today it can only write the choices as plain text, or use AskUserQuestion. That card is live, so a server update cancels it, and it ties up the orchestrator until I answer.

t3_pending_request_create would fit this exactly: the orchestrator posts a choice card per child result, ends its turn, and my click comes back as the next message. That only works if the tool is offered to every provider, not just those with no question tool of their own. Showing the open card on the orchestrator's sidebar row would also cover the client follow-up planned in #15082.

[denis229115]

Follow-up with a working prototype for the orchestrator case.

I built t3_pending_request_create on a fork and have been testing it locally. It is offered to every provider, not only those without a native question tool: Claude's AskUserQuestion is live, so it holds the orchestrator's turn open and a server update cancels it.

What it does

• It creates a user_input_request in the calling thread with responseCapability: { type: "message" } and returns the requestId immediately. The agent ends its turn, and the answer arrives as the next user message through the existing async-answer path that Codex questions already use.
• It takes a clientRequestId, as @kvnloo suggested: a retry returns the same card, recorded under the run that first asked it.
• The card is created inside the thread's serialized dispatch, so a Stop, archive or delete that wins the race leaves no card behind. Only a running turn can ask.
• Like a turn that ends normally, Stop keeps a pending card. Settling dismisses it; deleting the thread cancels it.

Input

• One to four questions, up to nine options each. header, question id and option description are optional and filled in, the way Claude questions are mapped today.
• Repeated question ids, two options that send the same value, and a question with no way to answer are rejected with a message the agent can act on.
• A multi-select answer is sent as the chosen values, comma-separated.

Three optional additions, shown in the screenshots

1. links on a question, http(s) only, shown as chips. A pull request link opens in the PR panel.
2. recommended on an option, shown as a badge.
3. A ‹ 1 of 3 › pager in the composer when several questions are waiting. Today only the oldest is shown.

[screenshot: card 2 of 3, a plan with two questions]

Tested so far

Claude Sonnet 5.5 posted three cards and ended its turn. I answered one by choosing options and one by typing my own answer; both arrived as messages after the turn had ended, and the thread showed Input in the sidebar while cards waited. Focused tests cover create, retry, multi-select answers, Stop, and the input checks.

Mobile: cards work in the mobile app too. An agent's card shows up there and answering it sends the reply back as the next message, with no mobile changes needed. The pager, links and badge are web-only so far; mobile shows the oldest waiting card.

Would you accept a PR for the tool? And should the three additions be separate PRs, or left out?

[KorenKrita]

Another data point from Pi: @juicesharp/rpiv-ask-user-question, a widely used ask_user_question extension for Pi.

In RPC mode it falls back to ctx.ui.select / ctx.ui.input. Under T3 that breaks in two places:

• Every multiSelect question goes through ui.input. T3 renders it as a single "Submit empty value" button, with the options folded into the header and the placeholder as the question. Filed as [Bug]: Pi extension input dialogs render as a single "Submit empty value" option, with the placeholder as the question #23494.
• The "Type something." follow-up is also ui.input, and it can fail the turn (Pi run fails with "Provider turn failed." when a question's "Type something" option opens a follow-up input dialog #22405).

As a local workaround I made the extension use only select when T3_PI_MCP_EXTENSION_PATH is set:

• Multi-select toggles options through repeated select cards until "Done".
• Custom text comes from the select card's own answer box.

It works, but it is clearly a stopgap: one card per toggle, no per-option descriptions, the title shown twice.

With t3_pending_request_create, an extension like this could detect T3 and post the questionnaire as one native card. That gives real multi-select and descriptions, and the questionnaire survives server updates. +1 to the non-blocking design. For an in-process extension, a clientRequestId (as suggested above) would also let it reattach after a /reload without posting a duplicate card.

[m4littlemozarts]

Another orchestrator case, from a Claude-only multi-agent setup on the 0.1.3 nightly.

Claude's AskUserQuestion holds the turn open, so a message from another T3 thread has two bad options today:

• Steer: the question is aborted but its card stays answerable, so my answer goes nowhere ([Bug]: Steering into a turn waiting on Claude's AskUserQuestion leaves a stale question that can't be answered #15517). One night I answered 10 dead cards in a minute.
• Queue: nothing gets through until I answer. One of my threads has six queued messages from other agents right now, and none of them depend on its question.

#22803 would clean up the dead card. #21158 would make every agent message to a running Claude turn wait in the queue, so the second case becomes the default. Neither lets a Claude thread keep working while its question waits. t3_pending_request_create with the message capability does, and @denis229115 already has it working. Would you take that PR?

Claude Opus 5.5 via T3 Code

[apophisnow]

We have this implemented, scoped to reuse what main already has:

• No new tool: t3_pending_request gains ask (1–4 questions, returns requestId) and dismiss.
• Same machinery: ask records the message-capability request, node and turn item that Codex async questions already use. Every client's question panel, dismissing, surviving restarts, and answers arriving as one user message all work unchanged.
• Idempotent: a repeated requestId is ignored, per @kvnloo's point.
• Claude: the related Claude bug is a separate PR, fix(claude): a steer or agent message no longer cancels Claude's question #26868. It moves AskUserQuestion onto the same requests, so a steer, a subagent message or a restart no longer kills the question.

The branch is apophisnow/t3code feat/agent-ask-questions, stacked on #26868. Maintainers: is this direction and scope OK to open as a PR?

[rgrvlsk]

+1 to apophisnow's proposal. I think it should land as is, offered to every provider and model.

The agent can then choose how to ask each question. If a wrong answer would be expensive to undo, it uses a blocking question and waits. If changing course later is cheap, it uses ask, takes its recommended option and keeps working.

In the second case, the user must be able to see which questions the agent asked and which recommendations it assumed. The open card could show this by marking the assumed option, so the user can correct it later.

On my machine, I chose the recommended option in 46 of 67 questions. That's often enough to proceed on when a mistake is cheap, but not often enough to hide the assumption.

Maintainers, can this land? The branch is stacked on #26868, which closed without merging.