Copilot CLI should send MCP cancellation requests

[rroesch1]

Summary

Copilot CLI does not send an MCP cancellation request when a tool call is
waiting for an in-flight URL-mode elicitation to complete. If the user
cancels the tool call while the authentication browser flow is pending, the
MCP server remains blocked until the elicitation or authentication flow
eventually returns.

Steps to reproduce

1. Start an MCP server that uses URL-mode elicitation for authentication.
2. Invoke a tool that triggers authentication.

{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"_meta":{"progressToken":1},"name":"foo","arguments":{}}}

3. Accept the Elicitation Request

{"jsonrpc":"2.0","id":1,"result":{"action":"accept"}

4. Cancel the tool call from Copilot CLI without finishing the authentication flow in the browser

Actual behavior

• Copilot CLI does not send an MCP cancellation request for the pending tool call.
• The server-side elicitation remains in flight.
• The tool call does not terminate promptly after the user cancels it.
• The server can remain blocked until the authentication flow's timeout

Expected behavior

When the user cancels the tool call, Copilot CLI should send an MCP
cancellation request for the associated in-flight request, as specified by
the MCP cancellation protocol. The server should then observe cancellation
through the request context and promptly terminate the pending elicitation and
tool call.

Impact

We have an MCP server that synchronizes elicitation requests to ensure that parallel tool calls do not trigger the same authentication flow multiple times.

If the user cancels the authentication flow (for example, by canceling the tool call), the server cannot release the synchronization lock because the client does not send an MCP cancellation request. As a result, the pending elicitation remains blocked, and all subsequent tool calls that require the same lock are also blocked until the authentication flow eventually times out or completes.

[veriton-dev]

Host-side cancel must be a first-class MCP notification, not a local UI state change

This is the classic three-layer mismatch:

1. UI cancel — user aborts the tool row / browser auth prompt
2. JSON-RPC request lifetime — the original tools/call id is still open on the wire
3. Server-owned side effect — URL-mode elicitation + any auth mutex the server holds

If only (1) flips and (2)/(3) are left to wall-clock timeout, every server that serializes auth (as described here) deadlocks the rest of the session.

What “send cancellation” should mean

Per the MCP cancellation pattern, cancel is a notifications/cancelled carrying the exact request id that is still outstanding — not a transport close, not a new tools/call, and not “stop rendering the spinner.”

Practical host checklist when the user cancels during URL-mode elicitation:

Host action	Why
Emit notifications/cancelled for the in-flight tools/call id	Server can drop elicitation + release locks
Keep the same request id; do not invent a sibling cancel RPC	Spec correlation is by id
Do not wait for the browser OAuth tab to finish before notifying	Browser UX is unrelated to JSON-RPC lifetime
Bound any local “await elicitation result” future with the cancel path	Avoid host hang even if server is slow
Surface a terminal tool result of kind cancelled, not error/timeout	Metrics + UX stay honest; retries stay safe
Only then tear down UI chrome	Order matters: notify → settle local future → UI

Failure matrix worth coding against

Sequence	Bad outcome if cancel is local-only	Desired
Cancel before elicitation accept	Server still waits on accept	Cancelled; no auth started
Cancel after accept, browser still open	Auth mutex held until OAuth timeout	Cancelled; mutex released promptly
Cancel while multiple tools share the same auth lock	Entire tool queue wedges	One cancel unblocks the queue
Transport drop without notifications/cancelled	Ambiguous: retry vs abandon	Prefer explicit cancel when user-initiated
Late elicitation result after cancel	Double-settle / spurious tool output	Drop late result; already terminal

Why transport-close is not a substitute

Closing stdio/SSE on cancel is too blunt: it kills the whole server session (discovery, other tools, progress). Cancel is request-scoped. Keep the session; kill only the open id. That is exactly what lets servers with “one auth flow at a time” recover without a process restart.

Acceptance checks (cheap)

• Cancel mid URL-elicitation → server logs/metrics show cancelled, not timeout, within a small bound (e.g. <1s after click).
• A second tools/call that needs the same auth lock proceeds after cancel without waiting for the OAuth wall clock.
• No second browser auth window spuriously opens from a raced retry.
• Host tool row ends as cancelled (not error); no SKU/retry storm.
• Integration test: mock server holds an elicitation promise; on notifications/cancelled it rejects and releases a mutex; assert a waiter unblocks.

Happy to refine wording if the team already has an internal cancel bus that just never mapped onto MCP notifications — the missing hop is almost always “UI cancel → request-id notify,” not a new protocol.