# Bug report: optional MCP server timeout blocks new Codex conversations

Resolved 💬 1 comment Opened Jun 22, 2026 by tiduse1988 Closed Jun 22, 2026

Bug report: optional MCP server timeout blocks new Codex conversations

Summary

Creating a new local conversation in the Codex desktop app can fail completely when an enabled optional MCP server is slow to respond. In this case, a configured remote MCP server named stitch caused every new conversation to fail with Timeout. Disabling that MCP server fixed the app immediately.

This is a severe product reliability issue: one optional MCP integration should not be able to block the core "new conversation" flow.

Environment

Product: Codex desktop app
Platform: macOS
App version observed in config/log context: 26.616.51431
Mode affected: Local new conversation / local task creation
MCP involved: stitch

User-facing symptoms

When creating a new conversation, the app showed errors such as:

创建任务时出错
Timeout

Earlier attempts also showed a misleading error:

no rollout found for thread id <thread-id>

Restarting the app and reinstalling the latest client did not resolve the issue.

Log evidence

Relevant log lines showed thread/start timing out at 30 seconds, while the response arrived roughly 40 seconds later:

mcp_request_timeout conversationId=none method=thread/start timeoutMs=30000
Failed to prewarm conversation errorMessage=Timeout
Error creating local task errorMessage=Timeout
[Composer] submit failed errorMessage=Timeout mode=local
response_routed method=thread/start durationMs=40116
No promise for request ID

There was also an MCP-status call around the same startup path:

response_routed method=mcpServerStatus/list durationMs=49502

After the timeout, the late thread/start response was orphaned by the client, producing:

No promise for request ID

Root cause isolated

The issue stopped after disabling the configured stitch MCP server:

[mcp_servers.stitch]
enabled = false

Before that, the config had the MCP enabled:

[mcp_servers.stitch]
enabled = true
url = "https://stitch.googleapis.com/mcp"

No prompt explicitly used this MCP. It appears the Codex app checked or prewarmed enabled MCP servers as part of new thread creation, and the slow MCP path blocked thread/start.

Expected behavior

Creating a new Codex conversation should not be blocked by an optional MCP server.
If an MCP server times out, Codex should degrade gracefully and continue creating the conversation.
The app should show a specific warning, for example:

MCP server "stitch" timed out and was skipped. You can disable it in Settings.

The MCP settings page should identify the failing MCP server.
The client should avoid orphaning late responses in a way that causes secondary errors like No promise for request ID.

Actual behavior

New conversations could not be created.
The user-facing error was generic (Timeout) or misleading (no rollout found for thread id ...).
Restarting and reinstalling did not help.
Only manually editing config.toml to disable the MCP fixed the app.

Impact

High. A single optional MCP configuration can make the whole Codex product unusable for local new conversations. The user cannot infer the cause from the error message.

Suggested fixes

Do not block thread/start on optional MCP server status/prewarm calls.
Apply per-MCP timeout isolation and continue without failed MCPs.
Surface the exact failing MCP name in the UI.
Add a one-click "disable failing MCP" action.
Handle late responses after timeout without producing confusing secondary errors.