Codex MCP OAuth client registration: CIMD or DCR for Sume

Codex registers with Sume's hosted MCP server by Dynamic Client Registration, because Sume's metadata advertises no Client ID Metadata Document support.

4 min readSume
All posts

When you sign Codex in to Sume's hosted MCP server, Codex registers itself by Dynamic Client Registration (DCR), not by a Client ID Metadata Document (CIMD). Codex only picks CIMD when the server's metadata says client_id_metadata_document_supported: true, and Sume's authorization-server metadata in current code lists a registration_endpoint and no such flag.

The Codex rules come from OpenAI's Codex MCP page and changelog, and the spec status from the MCP authorization page, all read 2026-09-29. The Sume side comes from the MCP quickstart, the OAuth page and the hosted server's OAuth code.

How does Codex choose between CIMD and DCR?

The Codex docs say it supports both. The default is auto, and a client ID you configure yourself skips registration entirely.

From Codex MCP documentation, read 2026-09-29.
SituationWhat Codex does
Server advertises client_id_metadata_document_supported: true, lists none in token_endpoint_auth_methods_supported, and the callback is a supported loopback URLUses CIMD
OtherwiseUses DCR when available
A client ID is configuredUses it and skips client registration

What does Sume's server advertise?

Sume's hosted MCP server runs its own authorization server at https://mcp.sume.com. Current code builds its metadata from a fixed list of fields, shown below. None of them is a CIMD flag, so the first row of the Codex table does not apply.

From the hosted MCP OAuth code and MCP OAuth, read 2026-09-29.
Metadata fieldValue today
registration_endpoint/oauth/register on the MCP origin
token_endpoint_auth_methods_supportednone
code_challenge_methods_supportedS256
grant_types_supportedauthorization_code
client_id_metadata_document_supportedNot listed

How do I sign in, and can I pick the method?

Add the server and run the login. Sume's quickstart tells Codex users to point a streamable HTTP server at the MCP URL and run that client's OAuth login. Codex shows the registration choice per login: --oauth-client-registration takes cimd or dcr, defaults to auto, and is not stored in config.toml.

codex mcp add sume --url https://mcp.sume.com/mcp
codex mcp login sume
# force the method for one login:
codex mcp login sume --oauth-client-registration dcr

Does Codex need a client secret for Sume?

No. Codex 0.158.0, listed in the changelog on 2026-09-28, added connecting to MCP servers that require pre-registered OAuth client secrets, including codex mcp add --oauth-client-secret. Sume's server is not one of them: in current code, registration accepts only token_endpoint_auth_method of none, so every client is a public client and there is no secret to pass.

Consent still happens on Sume's side: the default grant is read-only (mcp:read) and Write is a toggle on the consent page, as the OAuth page describes.

Is DCR going away?

The 2026-07-28 spec says authorization servers and clients SHOULD support CIMD, MAY support DCR, and that DCR is deprecated and retained for backwards compatibility. So DCR is the path that still works with servers like Sume's. Codex supports both, so a server that later adds CIMD support would not need a Codex change; this page describes only what Sume advertises as of the read date.

Sources

Related posts

More in Integrations

All Integrations posts

Written by Sume