Codex startup_timeout_sec 10 and tool_timeout_sec 60 for Sume

Codex defaults to a 10 s startup and a 60 s tool timeout per MCP server. Sume's jobs_wait holds at most 55 s, so the tool default only just fits.

4 min readSume
All posts

Codex's MCP docs give a startup_timeout_sec default of 10 and a tool_timeout_sec default of 60 for each server. For a Sume server, the 60-second tool default covers one jobs_wait slice, because Sume holds a wait for 55 seconds at most. The 10-second startup default is about how long Codex waits for the server to come up, and it is a client setting you can raise.

The two timers

The Codex values are from its docs page for the CLI. The Sume numbers are on the jobs and results page. The margin between 55 and 60 seconds is small, so a slow network can still produce a client-side timeout.

Codex MCP timeouts against Sume's wait (Codex docs and Sume docs, read 2026-10-06)
SettingDefaultApplies to
startup_timeout_sec (Codex)10Server startup
tool_timeout_sec (Codex)60One tool call
jobs_wait timeout_seconds (Sume)50 omitted, 55 capOne wait slice

What to set

If you see timeouts on long waits, lower the slice rather than raising the timer: ask for 45 seconds, and your call finishes with margin. You can also raise tool_timeout_sec for the Sume server in your config. Neither changes how long a job takes.

A client-side timeout is not a job outcome. The job keeps running and billing. Wait again on the same ids, and never submit the paid create again. Codex also lets you list enabled_tools and disabled_tools for a server, with the disabled list applied after the enabled one, which is a way to keep paid generators out of a session.

  • Keep jobs_wait slices at 45 to 55 seconds.
  • Raise tool_timeout_sec if your network adds delay.
  • Authenticate with codex mcp login <name> for OAuth, or use a bearer token variable for a key.

The tradeoff

A longer tool timeout hides slow networks but also hides a hung call for longer. A shorter slice gives you more calls and more output tokens in the conversation but fails fast. Most teams will be best served by leaving the defaults, using 45-second slices and watching for repeated timeouts before changing anything.

Remember too that Codex's startup_timeout_sec is separate from the tool timer. A server that is slow to connect on a cold start can fail that first check even though later calls would work, so if the server shows as failed only on the first launch, raise the startup value before you suspect Sume's credentials. Run codex mcp login again only if the sign-in itself failed.

Sources

Related posts

More in Integrations

All Integrations posts

Written by Sume