[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.

Not covered: the mobile app. It answers the oldest card, but has no pager, links or badge yet.

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