Desktop UI: new-thread send spinner is delayed by openaiDeveloperDocs MCP initialization

Environment

• Codex Desktop: 26.513.31313 (2867)
• Platform: macOS
• Repository: any workspace, including an empty temporary project

Summary

In Codex Desktop, sending the first message in a new thread can block in the UI before the message appears in the conversation. The send button spins for several seconds.

After bisecting ~/.codex/config.toml, the delay appears to be triggered by the bundled OpenAI Developer Docs MCP server configuration. When the MCP server is explicitly disabled, new-thread sends are immediate. When the enabled = false line is removed from [mcp_servers.openaiDeveloperDocs], the delay returns.

This looks like Desktop is blocking new-thread submission on MCP server status or initialization.

Reproduction

1. Configure Codex with the OpenAI Developer Docs MCP entry enabled implicitly:

   [mcp_servers.openaiDeveloperDocs]
   url = "https://developers.openai.com/mcp"
   
   [plugins."computer-use@openai-bundled"]
   enabled = true
   
   [plugins."browser@openai-bundled"]
   enabled = true
   
   [plugins."chrome@openai-bundled"]
   enabled = true
   
   [features]
   hooks = true
   memories = true
   chronicle = false

2. Restart Codex Desktop.

3. Open a workspace.

4. Start a new thread.

5. Send ping.

Actual behavior

The send button spins for several seconds before the message appears in the conversation.

Expected behavior

The message should enter the conversation immediately. MCP server status or initialization should not block the submit path for a new thread.

Bisected workaround

Adding enabled = false to the MCP server entry makes new-thread sends immediate again:

[mcp_servers.openaiDeveloperDocs]
enabled = false
url = "https://developers.openai.com/mcp"

[plugins."computer-use@openai-bundled"]
enabled = true

[plugins."browser@openai-bundled"]
enabled = true

[plugins."chrome@openai-bundled"]
enabled = true

[features]
hooks = true
memories = true
chronicle = false

Notably, with computer-use, browser, chrome, hooks, and memories enabled, sending is still fast as long as openaiDeveloperDocs is disabled.

Log evidence

Slow case with openaiDeveloperDocs enabled:

thread/start durationMs=12002
turn/start durationMs=5
mcpServerStatus/list durationMs=34453
mcpServerStatus/list durationMs=33735

Fast case with openaiDeveloperDocs disabled:

thread/start durationMs=72
turn/start durationMs=16
mcpServerStatus/list durationMs=26

Related issues

This feels related to the Desktop submit-path delay discussed in #18264 and the duplicate #18495, but this reproduction is specifically tied to the OpenAI Developer Docs MCP server status/init path on Desktop 26.513.31313.