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.

In Codex, add env_http_headers = { "x-api-key" = "SUME_API_KEY" } to the Sume server table and Codex will send the value of your SUME_API_KEY environment variable as an x-api-key header. Sume accepts either Authorization: Bearer <key> or x-api-key: <key> on hosted MCP, so both work in principle. Use bearer_token_env_var first, because it is the documented credential setting; reach for the header form when a proxy or policy needs x-api-key.
Sources: Codex: Model Context Protocol and Sume's MCP OAuth and API keys, read 2026-10-02.
What does env_http_headers do?
The Codex page defines http_headers as a map of header names to static values and env_http_headers as a map of header names to environment variable names, with the values pulled from the environment. Only the variable name goes in config.toml; the key stays in your shell or secret store. A third option, http_headers_helper, runs a local command that prints a JSON object of headers.
| Codex setting | What the page says | Sume side |
|---|---|---|
bearer_token_env_var | Env var holding a bearer token sent in Authorization | Authorization: Bearer <key> |
env_http_headers | Header name to env var name; values from the environment | x-api-key: <key> |
http_headers | Header name to static value | Avoid for keys: the secret lands in the file |
auth = "oauth" (default) | Stored MCP OAuth credentials | Consent on the MCP host; read-only unless Write is on |
[mcp_servers.sume]
url = "https://mcp.sume.com/mcp"
env_http_headers = { "x-api-key" = "SUME_API_KEY" }Which credential does Codex try first?
The page says the auth setting is the authentication Codex tries after configured bearer tokens and authorization headers, and that if no credential source resolves, Codex can connect to the server without authentication. It then tells you to run codex mcp login <name> for OAuth. It does not say whether a custom x-api-key header counts as an authorization header for that ordering. Treat that as untested.
How do I verify which credential Sume saw?
Call mcp_health. Sume's playbook says to confirm authenticated.auth_source, which reads mcp_oauth for an OAuth session. If you expected the key and see mcp_oauth, stored OAuth credentials won and the header was not what authenticated the session. Then call tools_list: an API-key session sees the full hosted set, while OAuth with only mcp:read sees read-only tools.
Unset the variable and the header cannot resolve, so run echo ${SUME_API_KEY:+set} in the shell that launches Codex before you debug anything else.
What stays true whichever header you use?
- Paid and write tools still require an
idempotency_keyon every call. - A key session has no
mcp:writetoggle; spend is wallet and admission checks, andmax_spend_usdapplies only when sent. - Rotate the key if it shows up in logs or chat, as Sume's credential-safety notes say. An OAuth token is not an API key, so do not copy one into the variable.
Sources
Related posts
More in Integrations
- 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.
- Copilot CLI 1.0.92: MCP tools after OAuth re-auth, with Sume
Copilot CLI 1.0.92-0 keeps MCP tools working after OAuth re-auth when definitions are unchanged. Sume tokens last one hour with no refresh, so you will hit it.
Written by Sume