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.

4 min readSume
All posts

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 credential options from its MCP page and Sume's accepted forms, read 2026-10-02.
Codex settingWhat the page saysSume side
bearer_token_env_varEnv var holding a bearer token sent in AuthorizationAuthorization: Bearer <key>
env_http_headersHeader name to env var name; values from the environmentx-api-key: <key>
http_headersHeader name to static valueAvoid for keys: the secret lands in the file
auth = "oauth" (default)Stored MCP OAuth credentialsConsent 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_key on every call.
  • A key session has no mcp:write toggle; spend is wallet and admission checks, and max_spend_usd applies 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

All Integrations posts

Written by Sume