claude-code - 💡(How to fix) Fix [BUG] Cowork: MCP elicitation/create returns cancelled — works correctly in Claude Code CLI [1 comments, 2 participants]

Summary

In Cowork (Claude Desktop), MCP elicitation/create requests from a custom MCP server are not surfaced to the user — the client returns an immediate cancelled response ({"action": "cancel"}) without ever rendering the elicitation UI. The same MCP server, talking to the same Claude version via Claude Code (CLI), correctly displays the elicitation form, accepts the user's input, and returns {"action": "accept", "content": {…}}.

This is a Cowork ⇄ Claude Code parity gap. Support for MCP elicitation was added to Claude Code under #2799 (assigned to @ollie-anthropic, marked done), but the same capability is not yet wired through to the Cowork session runtime, so any plugin author who relies on elicitation/create for interactive flows (project pickers, confirmation dialogs, credential prompts, destructive-action confirms) has those flows silently broken on the Cowork surface.

Surfaces affected: Cowork desktop (macOS, Windows) Not affected: Claude Code CLI / terminal, where elicitation works correctly

Expected behavior

When an MCP server inside a Cowork session sends an elicitation/create request, Cowork should:

1. Render an interactive form using the schema in the request, inline in the conversation.
2. Block the tool's execution turn until the user submits, declines, or cancels.
3. Return the structured response ({"action": "accept", "content": {…}}) back to the MCP server with the user's validated input.

This matches the behavior already shipping in Claude Code CLI and matches the Cursor reference UX described in #2799.

Actual behavior

The MCP server's elicitation/create request is acknowledged on the wire, but the Cowork client immediately returns:

{ "action": "cancel" }

with no UI ever shown, no spinner blocked, and no opportunity for the user to respond. From the MCP server's perspective the user "cancelled" within milliseconds — the same code path that works in CLI is silently broken on this surface.

This makes the failure mode worse than "not implemented": the server can't tell the difference between a user actively cancelling and Cowork returning a synthetic cancel, so retry logic and error messages aimed at the user end up misleading.

Reproduction steps

1. Take any MCP server that issues elicitation/create (e.g., the delete-project example from #2799 — server queries a list, asks the client which one to delete, then acts on the user's selection).
2. Connect the server first to Claude Code CLI:
   • Run claude in a terminal with the server registered.
   • Trigger the tool. Observe: elicitation form renders, user picks an option, server receives {"action": "accept", "content": {"project": "<choice>"}}.
3. Connect the same server to Cowork:
   • Add the same MCP server config in Claude Desktop.
   • Open a new Cowork task and trigger the same tool.
   • Observe: no UI renders, server logs show the request was answered with {"action": "cancel"} < 100 ms after dispatch.
4. Confirm the MCP server is otherwise healthy in Cowork (other tool calls succeed, only elicitation/create is short-circuited).

Reproducibility: 100% on the affected versions tested below.

Evidence

Claude Code (working) — server log:

[mcp:my-server] -> elicitation/create  schema=… message="Which project to delete?"
[mcp:my-server] <- elicitation/result  action=accept content={"project":"acme-prod"}

Cowork (broken) — server log, same server, same request:

[mcp:my-server] -> elicitation/create  schema=… message="Which project to delete?"
[mcp:my-server] <- elicitation/result  action=cancel
                   (returned in 47 ms, no user interaction)

The Cowork session itself shows no rendered widget, no pending state, and no record of the elicitation in the conversation transcript.

Environment

• Claude Desktop: 1.5354.0 (9a9e3d), built 2026-04-29T01:14:34Z
• OS: macOS 15.5
• MCP server transport: stdio
• Plan: Enterprise

Impact

• Any MCP server that depends on elicitation/create for interactive flows is silently broken on Cowork. The user experience is "the tool is misbehaving"; the actual cause is invisible.
• Plugin authors building for both surfaces have to either drop elicitation or maintain two divergent code paths (one for Claude Code, one for Cowork) — undermining the stated goal of "build once, run on every Claude surface."
• This blocks adoption of the elicitation pattern that #2799 was created to enable.

Related issues

• #2799 — Add support for MCP Elicitation — parent feature request, open, assigned to @ollie-anthropic. Implementation landed for Claude Code but does not extend to Cowork.
• #7108 — Add support for MCP Elicitation — duplicate of #2799 (closed).
• #48909 — Support custom stdio MCP servers in Cowork sessions — same parity-gap pattern (Claude Code supports stdio MCP, Cowork does not).
• #20377 — Local / desktop MCP tools not exposed to Claude Cowork, all the tools work properly in Claude chat — same parity-gap pattern.
• #42453 — Custom local MCP server tools disabled in Cowork and Claude Code, but work in Claude Chat Desktop app — same family.
• #47114 — AskUserQuestion auto-completes with empty answers — analogous bug in the first-party elicitation path (AskUserQuestion) where the client also returns immediately without surfacing UI. Worth checking whether the Cowork elicitation/create short-circuit shares a code path with this.

Requested fix

1. Preferred: Wire MCP elicitation/create through the Cowork VM bridge to the same renderer Claude Code uses. The MCP spec response shape (accept / decline / cancel) is already settled — Cowork just needs to render the form and return the user's actual choice instead of synthesizing cancel.
2. If full elicitation UI is not yet planned for Cowork, return {"action": "decline"} (with a reason like "elicitation not supported on this surface") rather than {"action": "cancel"} — so MCP servers can detect the parity gap and fall back gracefully instead of misinterpreting it as a user cancellation.
3. Document the current state explicitly on the [Cowork MCP support page] so plugin authors know to gate elicitation flows behind a surface check until parity ships.

Suggested workaround for plugin authors in the meantime

Detect the surface at MCP server startup (e.g., by checking the client info exchanged during initialization) and:

• On Claude Code: use elicitation/create normally.
• On Cowork: surface the same prompt as plain text in the tool's response (Please reply with one of: foo / bar / baz) and parse the user's free-form follow-up. Crude, but currently the only path that works on both surfaces.

Contact

Happy to provide:

• A minimal reproduction MCP server (Node.js, < 100 lines) that issues a single elicitation/create and logs the response action
• Side-by-side recordings of the same server in CLI vs Cowork
• Server logs with full request/response timestamps