MCP OAuth: DCR sends client_name "copilot-cli", rejected with 403 by Figma's allowlist (expects "GitHub Copilot CLI")

[jzm0720]

Summary

The CLI registers its OAuth client via Dynamic Client Registration with client_name: "copilot-cli". Figma's registration endpoint runs an allowlist on that field and rejects the value with 403 Forbidden. The transport dies before any browser opens, so the failure surfaces as a generic error with no indication that registration was the problem.

The string Figma expects — GitHub Copilot CLI — is already on their allowlist. This is a one-value mismatch, not a protocol incompatibility.

Reproduction

// ~/.copilot/mcp-config.json
{
  "mcpServers": {
    "figma": { "url": "https://mcp.figma.com/mcp" }
  }
}

Trigger authentication for the figma server. No browser opens. Logs show:

worker quit with fatal: Transport channel closed, when Client(OAuthChallenge { ... })

Or, surfaced to the user:

figma: RPC error -32603: Request session.mcp.oauth.login failed

Evidence

Captured by pointing figma.url at a local mock server and logging the registration request body verbatim:

{
  "client_name": "copilot-cli",
  "redirect_uris": ["http://127.0.0.1:55973/"],
  "token_endpoint_auth_method": "none",
  "grant_types": ["authorization_code", "refresh_token"],
  "response_types": ["code"]
}

Every field is valid. Probing Figma's registration endpoint directly (POST https://api.figma.com/v1/oauth/mcp/register) with only client_name varied:

client_name	Status
GitHub Copilot CLI	200
GitHub Copilot	200
Claude Code	200
Codex	200
copilot-cli	403
github-copilot	403
GitHub Copilot Chat	403
Cursor	403

Figma's status codes are diagnostic here: 403 means the name was rejected, while a malformed redirect URI returns 400 invalid_redirect_uri. Only the name varies across the table above.

Suggested fix

Send GitHub Copilot CLI as client_name during DCR. Figma already accepts it, and it is a more accurate display name for the consent screen that users see on any provider.

Workaround

A loopback proxy that rewrites client_name and forwards everything else unchanged. Confirmed working end-to-end against Figma, including tool calls.

Two non-obvious details for anyone attempting the same, both of which produce errors that look unrelated to the root cause:

1. RFC 8414 §3.3 — the CLI uses path-insertion discovery, requesting /.well-known/oauth-authorization-server/mcp. The issuer in the returned metadata must exactly equal that full URL including the path suffix, not the bare origin. Returning the origin yields Incompatible authorization server: authorization server advertised an issuer that does not match the URL its metadata was discovered from.

2. The 401 challenge — Figma's WWW-Authenticate header points discovery back at figma.com. Forwarded verbatim, the client routes around the proxy, re-registers as copilot-cli, and hits the original 403 again.

Notes

Figma has moved to remote-first; the local Dev Mode server on port 3845 is being retired and the desktop app no longer opens that port. There is no local fallback. The remote server is available on all plans including free, so this is not a seat or licensing issue — every Figma user on the CLI hits this.

Possibly related but distinct: #4870 describes a -32601 on server/discover against the same Figma endpoint, which occurs after authentication succeeds. The issue reported here occurs before any auth flow starts.

Environment

• macOS
• Figma remote MCP server (https://mcp.figma.com/mcp)