Claude Code URL prompts wait for "I'm done": does Sume send any?

Claude Code 2.1.288 now holds a tool call until you click "I'm done, continue" when an MCP server sends a URL prompt it cannot confirm completion for. Sume does not send URL prompts: sign-in happens in your client's OAuth flow, and nothing in Sume's MCP server code uses elicitation, so the new wait does not appear in a normal Sume session.

What changed in 2.1.288?

The Claude Code changelog (read 2026-10-03) has two linked entries. Version 2.1.287 (October 1, 2026): "Added URL prompts from MCP servers on the 2025-11-25 protocol, for example to sign in. If a server no longer connects after this update, add "bareElicitationCapability": true to its MCP config entry". Version 2.1.288 (October 2): "Changed MCP URL prompts from servers that can't report when you're done to wait for 'I'm done, continue' before the tool call continues, so you can finish in the browser first".

How does Sume ask you to sign in?

Through OAuth, outside the tool call. Per OAuth and API keys: the client connects to https://mcp.sume.com/mcp, gets a challenge and protected-resource metadata, and sends you to https://mcp.sume.com/oauth/authorize, which continues to the consent page on the MCP host. You pick Read, optionally Write, and the client exchanges the code (PKCE) for a token.

That is a connection-time step. By the time a tool runs, the session is already authenticated, so there is no sign-in to wait on in the middle of a call.

Does Sume ask for confirmation any other way?

Not through the protocol. Sume's spend gates are plain tool arguments: idempotency_key on paid and write calls, optional dry_run=true to preview cost, optional max_spend_usd to cap it. The docs call idempotency_key transport and dedup, not human approval. Approval for a paid call is your client's permission prompt, which you set per tool.

What if Claude Code stopped connecting to Sume after 2.1.287?

The changelog's remedy is the bareElicitationCapability flag in that server's config entry. Whether Sume needs it is not something Sume's docs state, so treat it as a client-side workaround to try only if a Sume entry that worked before actually stops connecting. Run claude mcp list first and read the status it gives.

claude mcp list
claude mcp get sume

Why does this matter for agents that run unattended?

A tool call that waits for a human click blocks a headless run. If you use Claude Code in scripts or CI against Sume, the safe pattern is an API-key remote entry, which sends Authorization: Bearer or x-api-key and needs no browser step at all. The docs describe that path as the one for automation that does not speak OAuth.

For an interactive session, OAuth is the documented preference. The two never mix inside a call: OAuth finishes before the first tool runs, and key sessions never involve a browser.

If you build your own MCP server next to Sume, the changelog entry is the thing to read: a server that opens a URL and cannot report completion now makes the client wait for a click. That is a design note for your server, not a Sume behavior. Sume's server instructions describe tools only, and its docs list no elicitation or URL step.

How do I check which prompts a server can send?

Ask the server for its own capabilities. Sume's mcp_health reports the endpoint, auth source and safety posture, and tools_list shows what you can call. Neither lists a URL step, because there is none. If you see a prompt in Claude Code that you did not expect from Sume, read the server name on the prompt before clicking; it may come from a different MCP server in the same session.

A sign-in prompt for Sume should always send you to mcp.sume.com, not to app.sume.com. Sume's docs say not to send interactive clients to app.sume.com for MCP OAuth, so a link to any other host is worth a second look before you continue.