Connect Codex to Cloudflare

What you get

Cloudflare’s docs list a general-purpose Cloudflare API MCP server at https://mcp.cloudflare.com/mcp, plus sixteen more scoped to a single product each. All of them sit on the *.mcp.cloudflare.com/mcp pattern except the Agents SDK one:

Server	Endpoint
Cloudflare API	https://mcp.cloudflare.com/mcp
Documentation	https://docs.mcp.cloudflare.com/mcp
Workers Bindings	https://bindings.mcp.cloudflare.com/mcp
Workers Builds	https://builds.mcp.cloudflare.com/mcp
Observability	https://observability.mcp.cloudflare.com/mcp
Radar	https://radar.mcp.cloudflare.com/mcp
Container	https://containers.mcp.cloudflare.com/mcp
Browser Run	https://browser.mcp.cloudflare.com/mcp
Logpush	https://logs.mcp.cloudflare.com/mcp
AI Gateway	https://ai-gateway.mcp.cloudflare.com/mcp
AI Search	https://autorag.mcp.cloudflare.com/mcp
Audit Logs	https://auditlogs.mcp.cloudflare.com/mcp
DNS Analytics	https://dns-analytics.mcp.cloudflare.com/mcp
Digital Experience Monitoring	https://dex.mcp.cloudflare.com/mcp
Cloudflare One CASB	https://casb.mcp.cloudflare.com/mcp
GraphQL	https://graphql.mcp.cloudflare.com/mcp
Agents SDK Documentation	https://agents.cloudflare.com/mcp

Each one is a separate remote MCP server with its own tools scoped to that product. Cloudflare doesn’t publish a combined tool list on that page, so once you’ve added a server, run codex mcp list and read the tool names off your own install rather than trusting a hardcoded list here.

Adding one of these is the easy part. The part worth planning is which of the seventeen you want live, because every server you enable is another OAuth login and another pile of tools sitting in front of the model. Pick the narrow server when the job is narrow. If all you want is Radar traffic data, add Radar instead of the general API server.

One thing Cloudflare’s page does not say is that any of these work without authentication. It documents an OAuth flow, and for the Cloudflare API server it documents an API token. It never describes a server as open. Plan on a login for every server you turn on, Documentation included.

Setup

Read Connect an MCP server first for the general TOML shape. If the CLI isn’t installed yet, start at Install Codex CLI.

Option 1: the plugin. Cloudflare’s Codex setup page tells you to run /plugins inside Codex, then “search for and install Cloudflare.” Cloudflare says this “installs Cloudflare Skills and registers the Cloudflare MCP servers.” The page doesn’t spell out which of the seventeen it registers or what it writes where, so if you want a specific subset, use option 2.

Option 2: hand-write the blocks. This is the one to use when you want several servers in the file but only one or two actually running. codex mcp add takes a --url for streamable HTTP servers:

codex mcp add cf-bindings --url https://bindings.mcp.cloudflare.com/mcp

That writes:

[mcp_servers.cf-bindings]
url = "https://bindings.mcp.cloudflare.com/mcp"

An entry gets url or command, never both, so no server in this table gets a command line. Codex’s auth key already defaults to "oauth", so leave it out.

Add the rest, and park the ones you aren’t using yet with enabled = false so they sit in the file without Codex trying to start them:

[mcp_servers.cf-docs]
url = "https://docs.mcp.cloudflare.com/mcp"

[mcp_servers.cf-radar]
url = "https://radar.mcp.cloudflare.com/mcp"
enabled = false

[mcp_servers.cf-dns-analytics]
url = "https://dns-analytics.mcp.cloudflare.com/mcp"
enabled = false

[mcp_servers.cf-browser]
url = "https://browser.mcp.cloudflare.com/mcp"
enabled = false

That’s four servers added and two of them live. Log into each one you enabled:

codex mcp login cf-bindings
codex mcp login cf-docs

The API token path. Cloudflare’s docs describe a token option for the general API server, aimed at CI/CD and automation: “you can create a Cloudflare API token with the permissions you need and pass it as a bearer token in the Authorization header.” That’s documented for mcp.cloudflare.com specifically. Cloudflare doesn’t say whether the same token works against the product-scoped servers, so don’t count on it until you’ve tried it yourself.

[mcp_servers.cf-api]
url = "https://mcp.cloudflare.com/mcp"
bearer_token_env_var = "CLOUDFLARE_API_TOKEN"

bearer_token_env_var names an environment variable Codex reads when it makes the request, so export the token in your shell and keep the value itself out of config.toml. That’s a separate mechanism from the [mcp_servers.<id>.env] sub-table, which passes variables into a local stdio process. A url server never spawns one. See mcp_servers.<id>.url for the remote endpoint keys.

Confirm the set:

codex mcp list

You want cf-bindings and cf-docs listed with a non-empty tool count. Parked servers stay dark until you flip enabled = true.

Gotchas

Cloudflare hands you JSON, Codex reads TOML. Cloudflare’s connection example is {"mcpServers": {"cloudflare-api": {"url": "https://mcp.cloudflare.com/mcp"}}}, which is the Claude Desktop shape. Codex doesn’t read that format at all. Translate it to [mcp_servers.cloudflare-api] with url = "..." per Connect an MCP server, or let codex mcp add <id> --url <endpoint> write it for you.

A 403 during OAuth discovery has a known cause. openai/codex #12859 is open: Codex’s rmcp HTTP client sends no User-Agent header, and Cloudflare’s bot protection answers with a 403 and an HTML body instead of the JSON OAuth metadata Codex is looking for. The reporter checked it with curl both ways, getting a 403 with no User-Agent and a 200 once they added one. Read the scope before you assume it applies here. The reporter names MCP servers hosted behind Cloudflare Pages and Workers with bot protection turned on, plus other CDNs and WAFs that check the same thing. They do not say Cloudflare’s own first-party servers in the table above are affected, and we haven’t reproduced it against them. If one of these does fail discovery with a 403, this is the first thing to check, and the reporter’s own workaround goes in the server block:

[mcp_servers.cf-bindings]
url = "https://bindings.mcp.cloudflare.com/mcp"
http_headers = { "User-Agent" = "codex-mcp/1.0" }

Codex’s config reference documents http_headers as “Static HTTP headers included with each MCP HTTP request,” so that’s a supported key rather than a hack. The reporter also proposes a permanent fix in codex-rs/rmcp-client/src/utils.rs to set a default User-Agent on all rmcp requests.

Two more open threads on the same dependency. #17529 is an open request to upgrade Codex’s rmcp dependency from 0.15.0 to 1.4.0, on the argument that the older version “lacks support for injecting custom HTTP headers” and that this “causes MCP connections to fail behind Cloudflare, strict corporate proxies, or services like Supabase.” #15815, closed as not planned, reported a different symptom from the same version: tool calls after a successful connection drop the mcp-session-id header, so connecting and listing tools both work while the calls themselves fail. If a Cloudflare server here connects fine but every call errors, that’s the one to read rather than the User-Agent issue.

One login per server. OAuth here is per-server. Logging into cf-docs does nothing for cf-bindings. Enable five of these expecting a single browser prompt to cover the set and you’ll be disappointed. Budget one codex mcp login per id you turn on.

Related

• Connect an MCP server: the general stdio/remote shape and the JSON-to-TOML translation table
• mcp_servers.<id>.url: the remote endpoint and its auth keys
• mcp_servers.<id>.env: the stdio sub-table, and why a remote server doesn’t use it
• mcp_servers.<id>.startup_timeout_sec: launch window if a server is slow to answer on first connect
• “handshaking with MCP server failed”: the connection dies at startup
• Install Codex CLI: if you’re setting this up before Codex itself