[BUG] Cowork: MCP elicitation/create silently auto-cancels (reproduced with a different MCP server than #56243/#48164)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported (as an open issue) — it was previously filed as #56243, auto-closed by a bot as a duplicate of #48164, then auto-locked after 7 days of inactivity so it can no longer receive comments. I believe #48164 is a distinct, narrower bug (server-initiated OAuth elicitation with mode: "url"), not the same failure as this one (plain form/confirm elicitation).
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code available in Claude Desktop

What's Wrong?

In Claude Desktop's Code tab (Cowork), when a connected MCP server sends an elicitation/create request (a plain confirm/decline form, no URL mode, no OAuth), the client returns almost instantly with the elicitation reported as declined. No UI is ever rendered, and the user sees nothing to respond to — at most a macOS notification that appears and disappears before it can be read.

From the MCP server's point of view, this response is indistinguishable from a real, deliberate user decline. That matters because it breaks the server's own graceful-degradation path: our server has a documented fallback specifically for clients that don't support elicitation (it stages the write and returns a pending_id the user can confirm later via a separate tool call, with the preview shown as plain chat text). That fallback never triggers here, because Cowork's client does apparently acknowledge the elicitation request — it just answers it with an immediate synthetic decline rather than either rendering the prompt or signaling non-support during capability negotiation.

What Should Happen?

One of two things, matching what already happens correctly elsewhere:

1. Cowork renders the elicitation prompt inline (as the terminal Claude Code CLI's TUI now does per #17043 in this repo), and blocks the tool call until the user responds, or
2. If rendering isn't implemented for this surface, Cowork should not declare/acknowledge the elicitation client capability at all, so MCP servers can detect non-support up front and take their own fallback path (as ours does) instead of receiving a false "user declined."

Steps to Reproduce

1. Connect Claude Desktop to a remote MCP server whose write tool triggers elicitation/create (a plain confirm/decline schema) before completing a write. (Any server implementing this — ours is an accounting product's MCP server, unrelated to whatever server was used in #56243.)
2. In Claude Desktop, open a session using the Code tab (Cowork) with that MCP server connected, in the same project scope.
3. Trigger the write tool.
4. Observe: the tool call returns within roughly 50ms reporting the write was cancelled/declined. No confirmation UI is shown. The MCP server's own fallback (pending_id staging) is never offered because the client's response looks like a genuine decline, not an "elicitation unsupported" signal.
5. For comparison, connect the same MCP server to the terminal claude CLI and trigger the same tool: elicitation still isn't rendered as a native dialog there either, but the server's staged-write fallback works correctly, shows a text preview, and completes the write once the user replies "yes" and the client calls the server's confirm-write tool.

So the terminal CLI ends up in a working state via graceful degradation, while Cowork ends up in a silently broken state that's indistinguishable from a real user rejection.

Error Messages/Logs

No error is surfaced to the user. The MCP server's write tool response was:

{"ok": false, "cancelled": true, "message": "Avbrutet — inget utlägg skapades."}

(Swedish for "Cancelled — nothing was created.")

Claude Model

Sonnet (default) — Claude Sonnet 5 (claude-sonnet-5)

Is this a regression?

I don't know — this is the first time I've used an MCP server with an elicitation-based write tool from Cowork.

Claude Code / Claude Desktop Version

Claude Desktop 1.52386.6 (Code tab / Cowork surface)

Platform

Anthropic API

Operating System

macOS 26.5.1 (build 25F80)

Terminal/Shell

N/A — this is Claude Desktop's Code tab, not a terminal surface

Additional Information

Related: #56243 (my independent reproduction of the same symptom, now locked and unable to receive comments), #48164 (the issue #56243 was auto-closed as a duplicate of — appears to cover a different, more specific case: elicitation/create with mode: "url" for server-initiated OAuth flows, not general form-based elicitation), #2799 and #17043 (elicitation support landing correctly in the terminal Claude Code CLI).

Happy to provide a minimal reproduction MCP server if that would help — the one I hit this with is a third-party production service I can't share credentials for, but the failure is generic to any server using elicitation/create.