Codex tool_timeout_sec is 60: size Sume jobs_wait to fit under it

Codex defaults tool_timeout_sec to 60 and startup_timeout_sec to 10. Sume's remote jobs_wait waits 50 seconds by default and never more than 55, so a single slice returns before Codex gives up. Keep the default, and call jobs_wait again when a slice ends instead of asking for a longer one.

Why the margin matters

The gap between 55 and 60 is only five seconds. A wait is one open HTTP request that moves no data, and the docs warn that an edge closes such a request at some point. The caller then gets no tool result while the job keeps running and billing. A short slice and a retry avoids that.

Config

Codex shares one configuration across the desktop app, the CLI and the IDE extension. Add the Sume URL as a streamable HTTP server. The Codex docs list url, bearer_token_env_var, http_headers and env_http_headers for HTTP servers. For OAuth, use the client's own login for the server name.

[mcp_servers.sume]
url = "https://mcp.sume.com/mcp"
tool_timeout_sec = 60
startup_timeout_sec = 10

The retry rule for the agent

Tell the agent what to do on wait_slice_expired: call jobs_wait again with the same ids. It must never submit the paid create again, because the original job is still running.

• Submit the paid call once, with a stable idempotency_key.
• Call jobs_wait with job_id and no custom timeout.
• On wait_slice_expired, repeat the same jobs_wait.
• On a 524, 522, 523 or 525, treat it as transport failure and wait again, or read jobs_status once.
• Read the answer with jobs_result after the job is terminal.

If you raise the Codex timeout

Raising tool_timeout_sec does not lengthen the Sume slice. The server caps it at 55 seconds, and the API clamps larger values and reports wait_slice_clamped. A higher Codex limit only hides a stuck call for longer.

Startup timeout

The 10-second startup_timeout_sec covers connecting and listing tools. The hosted endpoint is remote, so a slow network can exceed it. If Codex reports that the Sume server failed to start, raise the startup value a little, but leave the tool value at 60, since that is the one tied to the wait slice.

Run jobs_wait on a job that is still processing and note the time to answer. It should be near 50 seconds. If your network adds latency, the margin to 60 seconds shrinks, and you can pass a smaller timeout_seconds, such as 40, to the wait. Short slices cost only more calls, not more money, since a wait is a read.

A last point on retries. Because a wait is a read, repeating it costs nothing beyond time. That makes the loop of wait, expire, wait the cheapest part of a long render. What costs money is a second create, so put the create behind a guard: if a job id is already stored for this task, never create again. Codex can enforce this in your project instructions, and a stable idempotency_key gives Sume's side the same protection if the guard fails.