codex mcp add --oauth-client-secret: do you need it for Sume?
Codex CLI 0.158.0 added --oauth-client-secret for MCP servers that require a pre-registered client secret. Sume's OAuth uses public clients, so you can skip it.
You do not need codex mcp add --oauth-client-secret for Sume. Codex CLI 0.158.0, released September 28, 2026, added support for MCP servers that require a pre-registered OAuth client secret, including through that flag. Sume's hosted MCP is not that kind of server: its authorization server metadata lists token_endpoint_auth_methods_supported as none and offers a registration endpoint at /oauth/register, so Codex can register itself as a public client and use PKCE, with no secret to store.
The Codex facts are from the ChatGPT and Codex changelog, read 2026-10-01. The Sume facts are from the repository's OAuth metadata and OAuth and API keys.
When does a client secret apply?
A pre-registered client is for servers that hand you a client id and secret in a developer console and refuse dynamic registration, which is how many SaaS MCP servers with fixed app registrations work. The new flag lets Codex hold that secret. Sume does not issue one: there is no console step where you create an OAuth app for Codex, and a secret you invent would not be checked.
| Server type | What you give Codex | Example fit |
|---|---|---|
| Dynamic registration, public client | Nothing but the URL | Sume hosted MCP |
| Pre-registered client with secret | Client id and --oauth-client-secret | Servers that issue an app secret |
| Static key in a header | An environment variable name for the bearer token | Sume with an API key |
What should I run instead?
Add the server by URL and log in for the server name you chose, as in Sume's quickstart: Codex discovers the protected-resource metadata, then sends you to https://mcp.sume.com/oauth/authorize, which continues to the consent page on the MCP host. Leave Write off for exploration and on when Codex should create media.
If you run Codex unattended, skip OAuth. Sume's access tokens last one hour and no refresh token is issued, so an API key in a bearer header is the stable choice. Paid calls still need an idempotency_key.
Limits
I only read the changelog line for 0.158.0, not the full flag reference, so check codex mcp add --help for exact syntax on your build. If a future Sume release adds confidential clients, this answer changes; the metadata above is what the repository serves today.
Sources
Related posts
More in Integrations
- Codex env_http_headers: send the Sume key as x-api-key
Codex can send a Sume API key from an environment variable as an x-api-key header with env_http_headers. Config, caveats on auth order, and how to verify it.
- Codex enabled_tools: allowlist only read-only Sume MCP tools
Codex's enabled_tools setting limits which tools a Sume MCP server exposes. Here is an allowlist of Sume's read tools, and why it matters most for API keys.
- Codex MCP required = true: fail fast when the Sume server is down
Codex's required = true makes startup fail if an enabled MCP server cannot initialize. When to set it for Sume, and how the 1000 ms grace and 10 s timeout work.
- Convex HTTP action as a Sume webhook receiver: raw body, no retry
A Convex httpAction reads the raw body with request.text() and is not retried by Convex, so Sume's 10 delivery attempts and a job_id dedupe do the work.
Written by Sume