[BUG] form-mode MCP elicitation auto-declines in interactive TUI — server-initiated form is treated as "print mode"

Found 1 possible duplicate issue:

1. https://github.com/anthropics/claude-code/issues/48164

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Not a duplicate of #48164. The bot matched on the elicitation/create substring, but the two reports cover different MCP modes with different failure shapes and different documented contracts:

| | #48164 | #62319 (this issue) |
|---|---|---|
| Mode | url | form |
| Client response | Explicit RPC error -32602: Client does not support URL-mode elicitation requests | Silent non-accept; internal log labels it "Elicitation request received in print mode" |
| Documented contract | URL-mode is not promised as supported anywhere in the Claude Code docs | Form-mode is explicitly documented at https://code.claude.com/docs/en/mcp#respond-to-mcp-elicitation-requests as automatic: "Claude Code displays an interactive dialog … No configuration is required on your side" |
| Surface | Any transport / setup | Interactive TUI (no --print, no Agent SDK) on 2.1.144, after the v2.1.117 print/SDK fix referenced in #51785 |

Fixing #48164 (adding URL-mode support) would not fix this — form-mode is already advertised, the request reaches the client cleanly, and the client itself routes it to the headless code path instead of rendering the documented TUI dialog.

I can confirm the same failure shape with a different private local MCP server and a minimal boolean form schema.

Environment:

• Claude Code: 2.1.170 (Claude Code)
• macOS: 26.5.1, Darwin 25.5.0, arm64
• MCP server: private user-scoped local Node MCP server
• Invocation/surface: interactive Claude Code session, not -p / Agent SDK
• Tool shape: a confirmation tool that requests one boolean via form-mode elicitation

The server only enters the native elicitation path after seeing clientCapabilities?.elicitation?.form; otherwise it returns a normal chat-fallback instruction. The requested schema was a simple form-mode boolean:

{
  "mode": "form",
  "message": "Ready to close the active session?",
  "requestedSchema": {
    "type": "object",
    "properties": {
      "confirm_close": {
        "type": "boolean",
        "title": "Ready to close?",
        "description": "Turn this on only if you want to finalize the active session now.",
        "default": false
      }
    },
    "required": ["confirm_close"]
  }
}

Claude Code logged the request as print mode in an interactive session:

{
  "debug": "Elicitation request received in print mode: {\"method\":\"elicitation/create\",\"params\":{\"mode\":\"form\",\"message\":\"[redacted]\",\"requestedSchema\":{\"type\":\"object\",\"properties\":{\"confirm_close\":{\"type\":\"boolean\",\"title\":\"Ready to close?\",\"description\":\"[redacted]\",\"default\":false}},\"required\":[\"confirm_close\"]}}}",
  "timestamp": "2026-06-11T21:44:43.979Z",
  "sessionId": "[redacted]",
  "cwd": "[redacted]"
}

The tool failed immediately afterward because the elicitation result was not accepted. The gap from elicitation receipt to failure was about 8 ms, so no human interaction could have occurred. A second attempt one minute later had the same Elicitation request received in print mode log and failed within about 15 ms.

The server-side chat fallback then succeeded with the same tool once the confirmation was supplied explicitly in the tool arguments, so the MCP server and tool were otherwise healthy. The broken part was specifically native form-mode elicitation being routed through the print/headless path instead of presenting a usable dialog.

Confirming this on the latest claude-code builds (2.1.185–2.1.195) from the other side of the wire — a production MCP gateway/proxy that gates state-changing tool calls behind a server-initiated form-mode elicitation/create. Same root signature as @abecker93's repro (interactive session, request logged as "print mode", non-accept with no human in the loop), plus a second observable variant on the newest builds that I don't think is captured yet.

Two distinct failure shapes from the same misroute

(a) Fast auto-decline (~8–100 ms) — matches @abecker93 / @Evgenas above.

• Interactive claude CLI, default renderer, all permission modes tried.
• A createConfluencePage confirmation resolved as cancel in ~106 ms — far too fast for a human, no dialog ever shown.
• A 358-byte, single-line probe with no truncation cancelled the same way, so this is not the fullscreen-TUI clipping issue (#69087) — the prompt never rendered at all.
• Notably it worked only in --debug mode. Whatever selects the "print mode" path appears to differ when debug is on — likely a useful clue for narrowing the detection logic.

(b) Full no-response timeout (~5 min) — the variant I think is new here, on the latest release.

• Client claude-code/2.1.195 (cli), interactive session.
• Three createConfluencePage attempts, each ~5–6 min apart, all resolved as a server-side timeout because the client returned no JSON-RPC response at all — not accept, not decline, nothing — for the full elicitation window.
• Payload sizes 929 B / 912 B / 325 B; the 325 B one was a single line, untruncated, and still never got a response → again rules out clipping.
• Crucially, non-elicitation reads in the same session kept succeeding throughout, so the transport stayed up. The write simply parked on an elicitation that the client never surfaced or answered.

So in older builds the misrouted-to-"print mode" request comes back as a fast decline (a); on 2.1.195 the same misroute presents as the client silently dropping the request entirely (b). Both leave the server holding a confirmation that no human ever saw.

Server/proxy side is clean — verified against a reference client

To rule out our side, I replayed the identical form-mode elicitation/create (single boolean confirmed, required: ["confirmed"]) through MCP Inspector: it renders the dialog correctly, and accept → the gated write reaches the backend end-to-end. Same request, correct client → works. So the request shape is spec-valid and the divergence is purely in the claude-code TUI elicitation path, consistent with this issue.

Capability shape

Per #69555, the client advertises "elicitation": {} (post ~2.1.108), which per the 2025-11-25 spec still means form-mode supported — and indeed the request reaches the client cleanly rather than erroring. So this isn't a missing-capability problem (that's the separate url-mode track in #48164); it's an advertised-and-accepted form-mode elicitation being routed to the headless/"print mode" handler in an interactive session.

Summary for triage

| | shape (a) | shape (b) |
|---|---|---|
| builds seen | ≤ ~2.1.17x | 2.1.195 (latest) |
| surface | interactive TUI | interactive TUI |
| client response | non-accept in ~8–100 ms | none (server times out ~5 min) |
| dialog rendered? | no | no |
| payload | small, untruncated still fails | small, untruncated still fails |
| transport | up | up (concurrent reads succeed) |

Happy to provide more captures. The --debug-only success in (a) seems like the highest-leverage thread to pull on.

Follow-up after inspecting the bundled handler in 2.1.195 — two concrete findings that I think explain both the "auto-decline" shape in this issue and the no-response-timeout variant I reported above, and that point at small, self-contained fixes.

1. The "received in print mode" log is emitted unconditionally — it's a mislabel, not a mode check

The server-elicitation/create request handler that logs Elicitation request received in print mode: … logs that string at registration time, ungated — there's no isPrintMode/headless guard around it. So seeing it in a fully interactive session (as @abecker93 and @Evgenas did) is not evidence the session is in --print; it just means that session bound the control-protocol / SDK elicitation handler instead of the interactive TUI one. The label has almost certainly been sending triage in the wrong direction — it reads like a print-mode problem when the real signal is "this session bound the wrong handler."

2. The control-protocol elicitation forward has no timeout — its sibling does

There appear to be (at least) two server-elicitation handler implementations:

• an interactive one that enqueues the request onto the TUI render queue and resolves only when the user acts (or the request is aborted), and
• a control-protocol / SDK one that forwards the request as a control message (sendRequest({subtype:"elicitation", …})) and, on any error, returns {action:"cancel"}.

The control-protocol forward has no client-side timeout. The sibling user-dialog method on the same transport does — it arms a setTimeout that injects a cancelled response after a bounded interval. The elicitation forward omits that timer entirely.

That single asymmetry explains both observed shapes:

• Forward rejects (stream error / no consumer) → catch → {action:"cancel"} returns in milliseconds = the ~8–100 ms "instant auto-decline" in this issue.
• Forward is never answered (no surface consuming it) → it hangs for the full server-side elicitation window = the ~5-min no-response timeouts I reported on 2.1.195. The transport stays up the whole time (concurrent reads keep succeeding), which is exactly what a never-resolving in-flight request looks like.

Suggested fixes (smallest first)

1. Relabel / gate the log so it reflects the actual transport (control-protocol vs TUI) rather than always saying "print mode". This alone would make every future report of this class self-diagnosing.
2. Give the control-protocol elicitation forward the same self-cancel timeout the user-dialog path already has, so a never-answered elicitation fails fast and deterministically instead of parking until the server times out.
3. The deeper fix: ensure interactive / agent-view sessions bind the render-queue handler, not the control-protocol forward, when there's a real UI surface available.

Happy to share more captures (versions, payload sizes, timings). The behavioral repro is in my comment above; these two findings are just what the bundled handler shows about why it presents as it does.