Official Meta Ads MCP fails OAuth login with invalid_client_metadata

openai/codex #24103: Official Meta Ads MCP Fails OAuth Login with invalid_client_metadata

Executive Summary

The Meta Ads MCP server fails during OAuth login with an invalid_client_metadata error. This occurs because Codex's OAuth implementation uses Dynamic Client Registration (DCR) per RFC 7591 when no explicit client_id is configured, and the client metadata payload sent during DCR does not satisfy Meta's OAuth authorization server requirements.

The root cause is that the RMCP library's DCR implementation sends a minimal client metadata payload (primarily client_name: "Codex" and redirect_uris) that Meta's OAuth server rejects as non-compliant. Meta requires additional metadata fields such as token_endpoint_auth_method, specific grant_types, and potentially software_statement for client assertion.

Impact: P1 — Users cannot authenticate with the official Meta Ads MCP server at all. The error is unrecoverable without manual configuration workarounds.

Expected quote: $2,000–$3,000

Labels: bug, auth, mcp, CLI

Competition: 0 comments, 0 PRs (zero competition)

---

1. Problem Analysis

1.1 Error Reproduction

When a user attempts to authenticate with the Meta Ads MCP server:

codex mcp login meta-ads
# or during automatic MCP server startup

The OAuth flow fails with:

OAuth provider returned `invalid_client_metadata`: <description>

This error originates from Meta's OAuth authorization server rejecting the Dynamic Client Registration (DCR) request.

1.2 OAuth Flow Architecture

┌──────────────────────────────────────────────────────────────────┐
│                    CODEX CLI / APP-SERVER                        │
│                                                                  │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │  perform_oauth_login()                                   │   │
│  │  (rmcp-client/src/perform_oauth_login.rs:80)             │   │
│  │                                                          │   │
│  │  ┌────────────────────────────────────────────────────┐  │   │
│  │  │ start_authorization()                              │  │   │
│  │  │ (perform_oauth_login.rs:604)                       │  │   │
│  │  │                                                    │  │   │
│  │  │  if oauth_client_id.is_none():                     │  │   │
│  │  │    ┌────────────────────────────────────────────┐  │  │   │
│  │  │    │ OAuthState::new(server_url)                │  │  │   │
│  │  │    │  → Triggers DCR via                       │  │  │   │
│  │  │    │    POST /.well-known/oauth-                │  │  │   │
│  │  │    │    registration-server                      │  │  │   │
│  │  │    │    Body: {                                 │  │  │   │
│  │  │    │      "client_name": "Codex",               │  │  │   │
│  │  │    │      "redirect_uris": [...],               │  │  │   │
│  │  │    │      ...minimal metadata...                │  │  │   │
│  │  │    │    }                                       │  │  │   │
│  │  │    │    → FAILS: invalid_client_metadata        │  │  │   │
│  │  │    └────────────────────────────────────────────┘  │  │   │
│  │  │                                                    │  │   │
│  │  │  if oauth_client_id.is_some():                     │  │   │
│  │  │    ┌────────────────────────────────────────────┐  │  │   │
│  │  │    │ AuthorizationManager.configure_client()    │  │  │   │
│  │  │    │  → Uses pre-registered client_id           │  │  │   │
│  │  │    │  → Skips DCR entirely                      │  │  │   │
│  │  │    └────────────────────────────────────────────┘  │  │   │
│  │  └────────────────────────────────────────────────────┘  │   │
│  └──────────────────────────────────────────────────────────┘   │
└──────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌──────────────────────────────────────────────────────────────────┐
│                    META OAUTH SERVER                             │
│                                                                  │
│  POST /.well-known/oauth-registration-server                     │

I can reproduce this on Codex Desktop for macOS as well.

Environment:

• Codex Desktop bundled CLI: codex-cli 0.131.0-alpha.9
• Platform: macOS
• MCP server URL: https://mcp.facebook.com/ads

Commands:

/Applications/Codex.app/Contents/Resources/codex mcp add meta-ads --url https://mcp.facebook.com/ads
/Applications/Codex.app/Contents/Resources/codex mcp login meta-ads

Result:

Error: Registration failed: Dynamic registration failed: Registration failed: HTTP 400 Bad Request: {"error":"invalid_client_metadata","error_description":"Dynamic registration is not available for this client."}

codex mcp list shows the server is added and enabled, but auth remains Not logged in.

So this appears to reproduce the same failure mode: the OAuth browser consent flow never opens because dynamic client registration fails first.

Same here with codex v0.135.0

Same here.

still an issue

Any clue when this is going to be fixed?

Reproduced on macOS with the Codex desktop app / local CLI.

My MCP config is:

meta_mcp  https://mcp.facebook.com/ads  enabled  Not logged in

Clicking Authenticate in Codex does not open a browser. Running:

codex mcp login meta_mcp

fails immediately with:

Error: Registration failed: Dynamic registration failed: Registration failed: HTTP 400 Bad Request: {"error":"invalid_client_metadata","error_description":"Dynamic registration is not available for this client."}

So this is reproducible on a local Mac as well, not only on a remote/Linux setup.

+1, please address.

It still exists for more than a month now.

What happened? Will this be fixed?

Adding a user-impact note from Codex Desktop.

The Meta Ads MCP issue is not just a technical auth edge case. For small-business and marketing operators, this blocks a very natural workflow: connect Meta Ads, ask for campaign data, reason about the numbers, and then keep planning/executing in the same Codex session.

A smoother remote MCP OAuth flow would make Codex much stronger as a combined planning + execution workspace. The ideal experience is not only "chat" and not only "coding": users need an agent that can research, connect tools, pull data, reason over the business context, operate browser/UI when needed, and teach the user how to execute professionally while doing the work.

This kind of mode would help users learn to control AI tools instead of being replaced by them: fewer broken auth handoffs, clearer tool connection states, and a more fluid bridge between strategy, data, and action.

use meta cli from python, works fine. codex loves it. generate a token using the busniess manager "system user". took a bit (annyoing imo), but it works. codex is managing my ads now.

Reproduced again on 2026-07-15 with current local builds:

• Codex CLI: 0.144.1
• ChatGPT desktop/Codex app build: 26.707.72221
• Platform: macOS
• MCP URL: https://mcp.facebook.com/ads

codex mcp get meta_ads shows the streamable HTTP server enabled. Running codex mcp login meta_ads still fails before opening browser consent:

Error: Registration failed: Dynamic registration failed: Registration failed: HTTP 400 Bad Request: {"error":"invalid_client_metadata","error_description":"Dynamic registration is not available for this client."}

User impact: this prevents handing off an existing Meta Ads analysis/creative-production workflow from Claude’s hosted Meta Ads connector to Codex. Codex can read the local handoff and downstream attribution systems, but cannot authenticate to Meta for live spend/delivery or approved ad preparation. No bearer-token workaround should be required for the official hosted MCP endpoint.

Still same, any updates ?

Same issue here. It's really, really annoying. Codex would be great for this workflow, so I really hope this gets fixed soon.

Same issue here

Reproduced on Codex Desktop for Windows on 2026-08-02.

Environment:

• Codex Desktop client reported in logs: 26.727.51351
• MCP transport: Streamable HTTP
• Server: https://mcp.facebook.com/ads
• Configuration:

``toml
[mcp_servers.meta_ads]
enabled = true
url = "https://mcp.facebook.com/ads"
``

Observed behavior:

1. The MCP appears enabled and the UI shows Authenticate.
2. Clicking Authenticate repeatedly does not open a browser or show a visible error.
3. Restarting Codex does not change the behavior.
4. The MCP remains unavailable to Desktop threads.

Sanitized Codex log evidence:

resource metadata probe returned unexpected status: 405 Method Not Allowed
discovery url: https://mcp.facebook.com/.well-known/oauth-authorization-server/ads
resource metadata discovery url: https://mcp.facebook.com/.well-known/oauth-protected-resource/ads
worker quit with fatal: Transport channel closed, when AuthRequired(...)

The WWW-Authenticate response advertises Meta Ads scopes, including ads_management, ads_read, business_management, and ads_mcp_management, so the server is reachable and correctly requests OAuth. The flow stops before browser consent opens.

Control test:

• The same Meta account and the same endpoint authenticate successfully in Claude Desktop.
• This isolates the failure to Codex's MCP OAuth/DCR flow rather than the Meta account, browser, endpoint, or local MCP configuration.

Expected:
Codex Desktop should open the Meta consent flow and complete OAuth, or surface the exact registration/discovery failure in the UI.

No credentials, tokens, account IDs, campaign names, or local user paths are included in this report.