[BUG] Claude CLI: URL-mode elicitation/create not supported — server-initiated OAuth flows fails with not supported error

Status Open
Reported on v2.1.87
Maintainer reply None cached
Activity 9 comments · opened Apr 14, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Claude Code does not support elicitation/create with mode: "url" sent by MCP servers. This blocks server-initiated OAuth authorization flows during session setup (e.g. 3LO flows where the server needs the user to visit an authorization URL).

Setup:

  • Server declares "elicitation": {"url": {}} in initialize response capabilities
  • Client version .108 version declares "elicitation": {} in initialize request capabilities -> Note this can also be an issue where url mode is not supported.

Server sends elicitation/create mid/task (not as a response on any mcp api call)

json
{
  "jsonrpc": "2.0",
  "id": 100000,
  "method": "elicitation/create",
  "params": {
    "mode": "url",
    "elicitationId": "uuid",
    "url": <AUTH-URL>,
    "message": "Please authorize to continue."
  }
}

Response from claude --debug (mcp debug logs)

{"jsonrpc": "2.0", "id": 100000, "error": {"code": -32602, "message": "MCP error -32602: Client does not support URL-mode elicitation requests"}}

Testing with version 87

{"method": "initialize", "params": {"protocolVersion": "2025-11-25", "capabilities": {"roots": {}, "elicitation": {"form": {}, "url": {}}}, "clientInfo": {"name": "claude-code", "version": "2.1.87"}}, "jsonrpc": "2.0", "id": 0}

For similar elicitation:

Claude mcp logs provide info on:

 MCP server "server name": Elicitation request received during initialization: {"method":"elicitation/create","params":{"mode":"url","message":"Please authorize to continue.","elicitationId":"0f5e7464-72eb-40ce-aa06-511c258b7c9a","url":"<auth_url>"}}

No url shown to user and server received response:

 elicitation response (id=100000): {"result": {"action": "cancel"}, "jsonrpc": "2.0", "id": 100000}

What Should Happen?

Elicitation should be supported where:

  1. elicitation/create request should be handled properly and user should see the url.
  2. Elicitation capability should clearly reflect url mode. (it was declared in 87 but dropped in 108).

Error Messages/Logs

Version 108




{"jsonrpc": "2.0", "id": 100000, "error": {"code": -32602, "message": "MCP error -32602: Client does not support URL-mode elicitation requests"}}


Version 87 which declares the URL mode drops silently.



 MCP server "server name": Elicitation request received during initialization: {"method":"elicitation/create","params":{"mode":"url","message":"Please authorize to continue.","elicitationId":"0f5e7464-72eb-40ce-aa06-511c258b7c9a","url":"<auth_url>"}}


No url shown to user and server received response:


 elicitation response (id=100000): {"result": {"action": "cancel"}, "jsonrpc": "2.0", "id": 100000}

Steps to Reproduce

  1. Create a minimal stdio MCP server that declares elicitation.url capability

and sends elicitation/create with mode: "url":

python
#!/usr/bin/env python3
"""Minimal MCP server that sends URL-mode elicitation after initialize."""
import json, sys

def write(msg):
    sys.stdout.write(json.dumps(msg) + "\n")
    sys.stdout.flush()

for line in sys.stdin:
    msg = json.loads(line.strip())
    method = msg.get("method", "")
    msg_id = msg.get("id")

    if method == "initialize":
        write({
            "jsonrpc": "2.0", "id": msg_id,
            "result": {
                "protocolVersion": "2025-11-25",
                "capabilities": {"tools": {}, "elicitation": {"url": {}}},
                "serverInfo": {"name": "elicitation-test", "version": "1.0.0"},
            }
        })

    elif method == "notifications/initialized":
        # Send URL-mode elicitation to client
        write({
            "jsonrpc": "2.0", "id": 1,
            "method": "elicitation/create",
            "params": {
                "mode": "url",
                "elicitationId": "550e8400-e29b-41d4-a716-446655440000",
                "url": "https://example.com/authorize",
                "message": "Please authorize to continue.",
            }
        })

    elif method == "tools/list":
        write({"jsonrpc": "2.0", "id": msg_id, "result": {"tools": []}})

    elif "result" in msg or "error" in msg:
        # Log client's response to elicitation/create
        print(json.dumps(msg), file=sys.stderr)
  1. Save as elicitation_test_server.py
  1. Add to ~/.claude.json:

json

{
  "mcpServers": {
    "elicitation-test": {
      "type": "stdio",
      "command": "python3",
      "args": ["elicitation_test_server.py"]
    }
  }
}
  1. Run claude --debug
  1. Check stderr/debug logs for the client's response to elicitation/create

Expected: Claude Code shows the URL to the user with consent controls per MCP
spec.

Actual (v2.1.87): Client declares "elicitation": {"form": {}, "url": {}} in
capabilities but silently returns {"action": "cancel"}. User never sees the URL.

Actual (v2.1.108): Client declares "elicitation": {} and returns
{"code": -32602, "message": "Client does not support URL-mode elicitation requests"}

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.87

Claude Code Version

2.1.108

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

8 Comments

github-actions[bot] · 4 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/35353
  2. https://github.com/anthropics/claude-code/issues/41292
  3. https://github.com/anthropics/claude-code/issues/37092

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

smohite04 · 4 months ago

This is not duplicates of these.
https://github.com/anthropics/claude-code/issues/35353 says the VSCode extension silently drops but CLI supports.

I have experimented with latest version and even the older one. Claude CLI is not working for URL Mode Flow

Note: URL Mode With Elicitation Required Error Flow​ works with version.

Based on this, URL Mode Flow is still not working in spite of elicitation support.

github-actions[bot] · 3 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

jc · 2 months ago

The documentation says claude code supports url mode elicitation. But it is clear it doesn't. Please fix.

https://code.claude.com/docs/en/mcp#respond-to-mcp-elicitation-requests

kingjin94 · 2 months ago

Supporting voice here: Your documentation states "URL mode: Claude Code opens a browser URL for authentication or approval. Complete the flow in the browser, then confirm in the CLI." but rejects such requests. Remove it from your features or actually implement it please. It would help a lot in human in the loop context to unlock critical actions or authentification.

WubbbaLubbbaDubDub · 2 months ago

Adding to this from the MCP-gateway side, with a likely root cause that hasn't been mentioned here yet.

The regression is the capability shape: 2.1.87 advertised "elicitation": { "form": {}, "url": {} }; ~2.1.108 narrowed it to "elicitation": {}, which per the 2025-11-25 spec means form-mode only — so url-mode now hard-fails with -32602.

Why it likely happened, and why a fix is now safe: the narrowing lines up with older servers crashing on the new capability keys — the Java MCP SDK ≤ 0.17.1 threw UnrecognizedPropertyException: Unrecognized field "form" during initialize (#35389, open-metadata/OpenMetadata#26454). That was fixed server-side in Java SDK ≥ 0.18.0, so reverting the client to { "form": {}, "url": {} } no longer breaks those servers.

VS Code's Copilot MCP client already ships url-mode end-to-end (advertises {form,url}, opens the URL via its opener service, handles the -32042 retry) — a concrete working reference.

I've written this up with a minimal repro + reference-implementation pointers in #69555 — happy to consolidate there or here, whichever maintainers prefer. This blocks require-confirmation / human-in-the-loop approval and upstream OAuth/3LO for MCP gateways and proxies.

juliankolbe · 2 months ago

Is there a reason this is not getting fixed? This enables so many usecases for claude code. vscode copilot having it and claude code not, is kind of a shame.

dougdaulton · 1 month ago

Also hitting this — the capability-narrowing regression @WubbbaLubbbaDubDub pinned down ({form,url}{} between 2.1.87 and ~2.1.108, -32602 on url-mode) matches what we're seeing.

A couple of notes that might help:

  • We run several internal MCP servers built around human-in-the-loop approval gates (decision/review workflows that block an agent's next action until a person responds). On the affected client versions, elicitation/create comes back as an immediate {"action":"cancel"} — no UI ever renders, so the server can't tell "the client doesn't support this" from "the user actually declined." That ambiguity is worse than a hard error, since it drives bad retry/error-messaging logic downstream.
  • Possibly related, possibly a separate transport issue — flagging in case it's useful to whoever picks this up: we've also seen long-running waits on Claude Code CLI clients get killed with a -32001 timeout before the result arrives, once a wait exceeds roughly 55–60 seconds, independent of whether the human actually responded in time. We've had to work around it by bounding every wait to short polling intervals rather than trusting one long block call. If that shares a root cause with the elicitation short-circuit here, it might be worth tracking down together — both erode "wait for the human" as a reliable primitive.
  • This is blocking real human-in-the-loop workflows for us too, same as @jc and @kingjin94 — seconding the ask: given the root cause is now pinned down in this thread, is there a blocker to landing the fix?

Happy to provide a repro if useful.

Showing cached comments. Read the full discussion on GitHub ↗