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

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

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

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