ChatGPT Desktop: openaiDeveloperDocs makes thread/resume take 36 seconds
Summary
Enabling the first-party openaiDeveloperDocs streamable-HTTP MCP server makes opening/resuming an existing thread in the ChatGPT desktop app take about 36 seconds. Disabling only that MCP server and restarting the app reduces the same thread's thread/resume RPC to 110 ms.
This is a controlled A/B result on the same machine, app build, and thread. The Browser plugin remained enabled in both runs.
Environment
- ChatGPT Desktop:
26.707.51957(build5175) - Bundled Codex CLI:
0.144.0-alpha.4 - macOS:
26.5.2(build25F84), Apple Silicon - MCP transport: streamable HTTP
- MCP URL:
https://developers.openai.com/mcp
Configuration
Enabled case:
[mcp_servers.openaiDeveloperDocs]
url = "https://developers.openai.com/mcp"
enabled = true
Control case:
[mcp_servers.openaiDeveloperDocs]
url = "https://developers.openai.com/mcp"
enabled = false
browser@openai-bundled was installed and enabled in both runs. Its in-app browser backend reached startup_ready in a few milliseconds, so this comparison does not depend on disabling Browser.
Reproduction
- Add the first-party Docs MCP server:
``bash``
codex mcp add openaiDeveloperDocs --url https://developers.openai.com/mcp
- Ensure
enabled = trueformcp_servers.openaiDeveloperDocsin~/.codex/config.toml. - Quit and relaunch ChatGPT Desktop.
- Open an existing local Codex/ChatGPT thread.
- Inspect the Desktop log for
method=thread/resume. - Set only
mcp_servers.openaiDeveloperDocs.enabled = false, quit and relaunch the app, then open the same thread again.
Actual result
With openaiDeveloperDocs enabled, the log recorded:
2026-07-12T22:33:49.667Z maybe_resume_started
2026-07-12T22:33:49.673Z method=thread/read durationMs=3 errorCode=null
2026-07-12T22:34:25.933Z method=thread/resume durationMs=36233 errorCode=null
With only openaiDeveloperDocs disabled, after a full app restart, the same thread recorded:
2026-07-12T22:38:53.446Z maybe_resume_started
2026-07-12T22:38:53.455Z method=thread/read durationMs=5 errorCode=null
2026-07-12T22:38:54.847Z method=thread/resume durationMs=110 errorCode=null
That is a change from 36,233 ms to 110 ms (about 329× faster) with no thread/resume error in either run.
I also observed other existing threads taking 36,260 ms and 40,923 ms to resume while the Docs MCP was enabled.
Expected result
Opening or switching to an existing thread should not synchronously wait tens of seconds for a read-only, remote documentation MCP server. thread/resume should remain responsive when the Docs MCP is enabled.
Impact
The app is practically unusable for switching between existing chats when openaiDeveloperDocs is enabled. Disabling the MCP restores normal resume performance, but removes the first-party Docs MCP functionality.
Request
Please investigate the thread/resume / MCP lifecycle in the desktop app. Possible fixes include reusing the MCP connection, initializing the Docs MCP lazily or asynchronously, and exposing a timing breakdown for MCP initialization during thread/resume.
Related reports
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗