Codex MCP tool timeout: tool_timeout_sec and slow jobs

Codex allows an MCP tool call 60 seconds by default. To give a server's tools more time, set tool_timeout_sec on the server's [mcp_servers.<name>] table in config.toml. Server startup has a separate limit, startup_timeout_sec, which defaults to 10 seconds.

The Codex settings come from OpenAI's Codex MCP page and configuration reference, read on 2026-09-28. The slow-job example uses Sume's hosted MCP server and its Jobs and results docs.

Which Codex settings control MCP timeouts?

All of them live in ~/.codex/config.toml, or in a project's .codex/config.toml for trusted projects. The ChatGPT desktop app, the Codex CLI, and the IDE extension share this configuration.

How do I raise tool_timeout_sec?

Add the key to the server's table. For Sume's hosted server, which the MCP quickstart connects as a streamable HTTP server:

• Then run codex mcp login sume to finish the OAuth sign-in.
• The value is per server, so a slow server can get more time without changing the others.
• startup_timeout_ms is an alias for startup_timeout_sec in milliseconds, and required = true makes startup fail if the server can't initialize.

[mcp_servers.sume]
url = "https://mcp.sume.com/mcp"
tool_timeout_sec = 120
startup_timeout_sec = 20

Why does a media generation call hit the timeout?

A tool that holds the call open until a video finishes rendering can need more than a minute. A higher limit only helps so far: Sume's Jobs and results page notes that every edge eventually closes a request held open with nothing transferring, and the caller then gets no tool result while the job keeps running and billing.

Sume's generation tools avoid this by returning quickly. The video API is asynchronous: a submit answers with a job id right away (Video API). In current code, generate_image over MCP submits in async mode too. The agent then calls jobs_status or jobs_wait, and reads jobs_result when the job is done (MCP tools and gates).

Does a longer timeout make jobs_wait wait longer?

No. On Sume's remote MCP, one jobs_wait call holds at most 55 seconds, with a default of 50, so it already fits inside Codex's 60-second default and a higher tool_timeout_sec doesn't stretch it. For a longer render the agent calls jobs_wait again on the same ids and never resubmits the paid create; MCP tool call timeouts on long video jobs covers the slice outcomes and batch waits.

The risk runs the other way. Codex's own sample config sets tool_timeout_sec = 45, and a wait slice can run to 55 seconds. If you lower the limit below 55, keep a wait's timeout_seconds under it, or Codex gives up on a wait the server is still holding.

What should I do after Codex times out on a tool?

Treat the timeout as a lost response, not a failed job: Sume's docs say not to resubmit the original paid request just because a local process timed out. If the timeout hit a wait, the job id is already in the conversation, so have the agent call jobs_status on it. If there is no id, list recent jobs with jobs_list before submitting anything again. Can Codex make videos? covers adding a video tool to Codex in the first place.