[BUG] Claude CLI: URL-mode elicitation/create not supported — server-initiated OAuth flows fails with not supported error
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:
- elicitation/create request should be handled properly and user should see the url.
- 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
- 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)
- Save as
elicitation_test_server.py
- Add to ~/.claude.json:
json
{
"mcpServers": {
"elicitation-test": {
"type": "stdio",
"command": "python3",
"args": ["elicitation_test_server.py"]
}
}
}
- Run
claude --debug
- 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_
Showing cached comments. Read the full discussion on GitHub ↗
8 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
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.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
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
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.
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"duringinitialize(#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-32042retry) — 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.
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.
Also hitting this — the capability-narrowing regression @WubbbaLubbbaDubDub pinned down (
{form,url}→{}between 2.1.87 and ~2.1.108,-32602on url-mode) matches what we're seeing.A couple of notes that might help:
elicitation/createcomes 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.-32001timeout 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.Happy to provide a repro if useful.