ChatGPT Desktop: openaiDeveloperDocs makes thread/resume take 36 seconds

Open 💬 3 comments Opened Jul 12, 2026 by shurgalin

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 (build 5175)
  • Bundled Codex CLI: 0.144.0-alpha.4
  • macOS: 26.5.2 (build 25F84), 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

  1. Add the first-party Docs MCP server:

``bash
codex mcp add openaiDeveloperDocs --url https://developers.openai.com/mcp
``

  1. Ensure enabled = true for mcp_servers.openaiDeveloperDocs in ~/.codex/config.toml.
  2. Quit and relaunch ChatGPT Desktop.
  3. Open an existing local Codex/ChatGPT thread.
  4. Inspect the Desktop log for method=thread/resume.
  5. 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

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗