[BUG] VS Code extension still auto-declines MCP form elicitation (onElicitation not wired) — 2.1.287

Status Closed — duplicate
Reported on v2.1.287
Maintainer reply None cached
Activity 1 comment · opened Oct 2, 2026 · closed Oct 11, 2026

Re-filing as asked by the bot on the locked issues: same problem as #41292 (closed as a duplicate of #35353, which was closed as not planned and locked). It still happens in 2.1.287, and it is not limited to URL elicitation: form elicitation is declined too.

Environment: Claude Code VS Code extension 2.1.287 (win32-x64), agent-sdk 0.3.286, Windows 11. MCP server over streamable HTTP. Negotiated protocol 2026-07-28 (protocolEra: modern).

What happens: the MCP server returns a form elicitation (input_required with mode: "form", a oneOf choice and a string field). The Claude Code log shows it arriving:

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

No dialog appears in the VS Code chat panel. The server immediately gets action: "decline".

Why (from the bundled extension.js): the SDK control-request handler is

else if ($.request.subtype === "elicitation") {
  if (this.onElicitation) { ... }
  return { action: "decline" }
}

The extension never passes an onElicitation handler to the query, so every MCP elicitation is declined without being shown.

Expected: the extension shows the elicitation form in the chat panel, like the terminal CLI does, and returns the user's answer.

Repro: connect any MCP server that answers a tool call with a form elicitation, call that tool from the VS Code extension, and compare with the same call from the terminal claude.

Impact: MCP servers that ask for a human approval (apply / reject a proposed change) cannot do it in VS Code; the user has to leave the editor.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗