Codex MCP OAuth 503 on discovery: check Sume's two URLs

If Codex reports a 503 during MCP OAuth discovery, request Sume's two public metadata URLs with curl -i and read the status line. In Sume's server code both handlers answer with a plain 200 JSON body, so a persistent 503 more likely comes from another hop or a transient fault than from the metadata routes.

Codex CLI 0.156.0 (2026-09-22) lists a fix to "refresh MCP credentials when OAuth discovery returns a 503 error". The changelog line says no more than that. Sume URLs are from MCP OAuth and API keys, read 2026-10-01.

Which two URLs does Codex need from Sume?

Sume documents both as public metadata endpoints on the MCP host. The protected-resource document says which authorization server to use (authorization_servers is the MCP origin, not www or app.sume.com); the authorization-server document describes that server.

curl -i https://mcp.sume.com/.well-known/oauth-protected-resource/mcp
curl -i https://mcp.sume.com/.well-known/oauth-authorization-server

What does a healthy response look like?

A 200 status with a JSON body. The code also serves protected-resource metadata at the root /.well-known/oauth-protected-resource path. If both return 200 from your network, discovery is not failing at Sume's metadata routes.

What if one of them is not 200?

Copy the status code and, if the response carries one, the Sume request id from the headers, and report those; Sume's error docs say the request id is exposed in response headers. Leave API keys and signed URLs out of any report. Try again from a different network too, since a corporate proxy can return its own 503.

Is it safe to just retry in Codex?

Codex's own fix refreshes credentials after the 503, per its changelog. Discovery is read-only: it submits no generation, so a retry cannot create a paid job. Once the session is connected, paid and write tools still need mcp:write and an idempotency_key. For registration steps, see Codex MCP OAuth client registration for Sume.