Claude MCP elicitation requests are declined without an approval prompt#14878

Triage

Thanks for the precise diagnosis, @diastidean! Confirmed: Claude declines MCP elicitation/create because the adapter never handles it. This is a bug in the existing app-access approval path, not a new workflow.

makeClaudeAdapter in apps/server/src/provider/Layers/ClaudeAdapter.ts passes canUseTool and onUserDialog (with supportedDialogKinds: ["resume_return"]) into createQuery, but it never sets onElicitation. There's no ClaudeAdapterV2; this is the adapter in question. In @anthropic-ai/claude-agent-sdk@0.3.276, onElicitation is the callback for these requests, and when it's missing and no Elicitation hook answers first, the SDK declines. onUserDialog is a different control request and never sees them. The full-access auto-allow inside canUseTool doesn't cover them either, so the decline happens in every runtime mode. The ignored elicitation_complete system subtype isn't part of this path. It's also separate from the ACP elicitation/create handling in merged #11294.

Codex already shows this kind of request on the existing card: mcpServer/elicitation/request becomes request.opened with requestType: "mcp_elicitation_approval", which web and mobile render as mcp-elicitation. A fix should reuse that event rather than going through canUseTool or AskUserQuestion.

Your proposed narrow scope looks right to me, but it still needs a maintainer to confirm before you open a PR. Here's what that PR would cover:

• Handle onElicitation on the Claude query.
• Open the existing app-access card only for an approval-only form, and wait for the user. Use request.message as the detail, and for the app name use displayName, falling back to title and then serverName.
• Return { action: "accept", content } only after an explicit accept. Fill content the way Codex's toMcpElicitationResponse does for a one-time "accept": approval choices meaning once/accept/approve/allow, plus defaults. If a required field still can't be filled, decline without opening a card.
• Return decline and cancel as those actions. Never return null, because the SDK treats it as "already answered out of band" and the elicitation would otherwise hang until timeout.
• Fail closed with decline and no card for URL-mode elicitations and for forms asking for a value this card can't collect. Don't open the URL.
• One-time accept only: no acceptForSession, no acceptAlways, and no Claude permission rules written. Web and mobile both offer a session grant when options is omitted, so the opened request needs explicit Cancel, Decline, and Approve options.
• Park the wait on the session's existing pending-approval map so respondToRequest resolves it and stopping the session cancels it. The SDK callback's requestId is not T3's approval id.

Focused adapter tests should cover these cases:

• An approval-only form waits and only accepts after respondToRequest.
• Decline and cancel map to those actions.
• URL forms and value forms decline without showing a card.
• Aborting before the listener attaches, and stopping while the card is open, both settle as cancel.
• A late response after the request is gone hits the existing unknown-request error and doesn't settle twice.

URL auth, a form renderer, and session or always grants would stay out of scope.

@juliusmarminge Thanks for the triage on this. I’ve rebased #14895 and added focused test and manual verification evidence. Could you or another maintainer confirm whether the narrow, one-time Claude MCP approval scope is approved under the contribution guide? Happy to adjust or close the PR if this isn’t the desired direction.

We hit this too. We run T3 Code v0.0.45 as a shared agent for our team. One of our MCP servers asks for confirmation through elicitation/create before an expensive action: a form with one required enum field. Codex threads show T3's approval card as expected. Claude threads get an immediate decline with no card, so for Claude we have to fall back to a confirmation outside the approval UI.

A fix along the lines of #14895 would cover our case: register onElicitation, route approval-only form elicitations to the existing approval card, and fail closed for anything else. We're happy to test a build.

Checked current main at 89fe509232: the Claude adapter still registers onUserDialog without onElicitation. This is source inspection, not an independent runtime reproduction. Open #21903 already targets this exact issue and replaces closed #14895. Leaving this issue open for maintainer review of that work; no duplicate fix PR created. The approval-handling change requires Julius under the triage sensitive-surface rule.

Still reproducible on T3 Code Desktop 0.1.3-nightly.20261026.3726 (Linux), Claude thread.

The agent called the Supabase MCP execute_sql tool with a statement that deletes rows. The tool's description says destructive statements may require user confirmation. The call returned {"status":"declined"} about 19 seconds later with no approval card, three attempts in a row, with the user watching the window. Read-only queries through the same tool work. This matches the missing onElicitation handler described above, and #21903 looks like the fix.

Impact: it blocked a planned production database change, so the SQL had to be run manually in the vendor's dashboard.

Closing: this is covered by #21903, which landed. Reopen if an important part is still missing.