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