MCP elicitation: capability is declared but requests are auto-declined ("print mode") in interactive VSCode sessions

Summary

In an interactive VSCode-extension session, Claude Code declares the MCP elicitation capability during initialize, but auto-declines every elicitation/create request without showing any UI. The same session can render permission prompts and AskUserQuestion option dialogs, so it is clearly capable of interactive prompting — only the MCP elicitation path is unwired and silently rejected.

Because the capability is declared, servers cannot detect the situation:

• ServerSession.check_client_capability(ClientCapabilities(elicitation=...)) returns true
• ctx.elicit(...) does not raise; it returns a normal non-accept result
• From the server's perspective this is indistinguishable from a human explicitly declining the dialog

Impact

Any MCP server that implements a two-phase destructive operation ("show dialog → proceed on accept, abort on decline") dead-ends: the auto-decline is interpreted as a user cancellation, and the operation becomes impossible from Claude Code while working fine from elicitation-capable clients (e.g. Claude Desktop). We had to patch our server to treat decline as "declined or unavailable" and fall back to a confirmation-token flow, which weakens the semantics of a real user decline for every other client.

Repro

1. Minimal Python MCP stdio server (FastMCP / mcp SDK) with a tool that calls ctx.elicit(message=..., schema=...).
2. Register it in .mcp.json, run a Claude Code session from the VSCode extension.
3. Ask Claude to call the tool.
4. The tool returns immediately with a non-accept elicitation result; no dialog is shown.

MCP log (~/Library/Caches/claude-cli-nodejs/<project>/mcp-logs-<server>/*.jsonl):

{"debug":"Elicitation request received in print mode: {\"method\":\"elicitation/create\",\"params\":{\"mode\":\"form\", ... }}", ...}

Note the log says "print mode" even though the session is interactive (permission prompts and AskUserQuestion render fine in the very same session).

Expected behavior (any of these would fix it)

1. Do not declare the elicitation capability in session types that will not render elicitation UI — then check_client_capability lets servers fall back cleanly; or
2. Render elicitation via the same prompt surface already used for permission prompts / AskUserQuestion in these sessions; or
3. Respond with a distinguishable error (e.g. method-not-supported) instead of a synthetic decline, so servers can tell "client cannot ask" apart from "user said no".

Environment

• Claude Code 2.1.41 (VSCode extension, VSCode 1.129.0)
• macOS 26.5 (darwin)
• MCP server: Python mcp SDK / FastMCP, stdio transport

ClientCapabilities { ..., elicitation: Some(ElicitationCapability { form: None, url: None }) }

error = "User cancelled/dismissed the request"