›_ Codex Issues
Codex Issues / #23476

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

Open 💬 3 comments Opened May 19, 2026 by du953c
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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:

```toml
[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
```

  1. Restart Codex Desktop.
  2. Open a workspace.
  3. Start a new thread.
  4. 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.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #22072

Powered by Codex Action

du953c · 3 months ago

Thanks for the duplicate detection. I reviewed #22072. This may be related at the MCP timeout/status layer, but I don't think it is an exact duplicate.

#22072 is about Codex CLI hanging during pre-initialize OAuth bootstrap for Streamable HTTP MCP servers with saved OAuth credentials.

This issue is specifically about Codex Desktop UI blocking the new-thread submit path. The repro uses the public OpenAI Developer Docs MCP server:

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

Removing only enabled = false from this server makes Desktop's first send in a new thread spin for several seconds before the message enters the conversation. With the same plugins/features enabled but this MCP disabled, sending is immediate.

So the common area may be MCP startup/status timeout behavior, but the observable bug here is Desktop waiting on MCP status/init before accepting a new-thread message.

OrezzerO · 1 month ago

I reproduced the same new-thread delay on Codex CLI 0.144.5 and found a scoped workaround that keeps the OpenAI Docs MCP enabled:

[mcp_servers.openaiDeveloperDocs]
url = "https://developers.openai.com/mcp"
http_headers = { Authorization = "Bearer anonymous" }

In my controlled run, /new improved from about 15 seconds to 2.96 seconds. The Docs MCP still exposed all 5 tools, and search_openai_docs completed successfully.

The blocking time was in session_init.auth_mcp, not MCP initialization. With no configured credential source, Codex eagerly performs OAuth capability discovery for the streamable HTTP endpoint. The anonymously usable Docs endpoint returns 405/404 for the negative discovery probes, and the full discovery sequence plus retry/backoff accounted for about 12 seconds. An explicit Authorization header makes auth_status_before_discovery() classify the config as bearer-token auth and skip discovery; the Docs endpoint currently tolerates the placeholder header.

startup_timeout_sec does not cover this phase because it happens before mcp_manager_init.

Full timings, source paths, explanation, and caveats are in: https://github.com/openai/codex/issues/32654#issuecomment-4999764380

This is only a workaround for an endpoint known to work anonymously and tolerate the header. The client-side fix should keep optional MCP OAuth discovery off the synchronous thread/start path, cache negative discovery, or support an explicit auth = "none" mode.