ChatGPT Desktop: openaiDeveloperDocs makes thread/resume take 36 seconds #32654

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   mcpIssues related to the use of model context protocol (MCP) serversIssues related to the use of model context protocol (MCP) servers

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   performance

   on Jul 12, 2026
2. github-actions commented on Jul 12, 2026

   

   github-actionsbot

   on Jul 12, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [Codex app] Opening existing local conversations stalls 10–45s in thread/resume #32068

   Powered by Codex Action
3. shurgalin commented on Jul 13, 2026

   

   shurgalin

   on Jul 13, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   Update — reproduced after updating the desktop app.

   Environment:

   • ChatGPT Desktop 26.707.62119 (build 5211)
   • bundled app-server 0.144.2
   • macOS 26.5.2 (25F84), Apple Silicon

   With openaiDeveloperDocs enabled, I restarted the app and opened an existing local thread. The log recorded:

   2026-07-13T08:30:58.479Z maybe_resume_started
   2026-07-13T08:30:58.485Z method=thread/read durationMs=3
   2026-07-13T08:31:13.323Z method=thread/resume durationMs=14811 errorCode=null
   

   So the issue still reproduces on the newer build (14.8 seconds). This is lower than the prior ~36 seconds, but still makes switching to an existing chat unusable.

   Additional context: in the same startup, app/list took 13,404 ms and a later mcpServerStatus/list took 16,184 ms. This may indicate a broader initialization/lifecycle bottleneck rather than a Docs-MCP request itself.

   After I disabled the Docs MCP, switching to another existing thread in the running app took 55 ms. I am not treating that last comparison as a fresh-restart A/B; the controlled restarted A/B remains in the original report.
4. OrezzerO commented on Jul 17, 2026

   

   OrezzerO

   on Jul 17, 2026

   More actions

   I reproduced this on Codex CLI 0.144.5 and found a working scoped workaround that keeps openaiDeveloperDocs enabled.

   Workaround

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

   After restarting Codex, /new went from about 15 seconds to about 3 seconds, while the Docs MCP still exposed all 5 tools. I also successfully called search_openai_docs after the change (37 results for Codex MCP configuration).

   Controlled timing from logs_2.sqlite:

   • Before: thread/start at 14:05:16.516; session_init.auth_mcp did not finish until about 14:05:28.697; Docs MCP tools were ready at 14:05:31.534.
   • With the config above: thread/start at 14:12:38.616; the Docs MCP 5-tool list was available at 14:12:41.573 (about 2.96 seconds total).

   Why it works

   The delay is not primarily the Docs MCP initialize request. It occurs earlier in session_init.auth_mcp.

   For a streamable HTTP MCP with no configured credential source, Codex calls compute_auth_statuses(), then determine_streamable_http_auth_status(). The latter performs eager OAuth discovery before MCP initialization. For https://developers.openai.com/mcp, that negative discovery path probes the MCP URL and several /.well-known/... endpoints. The endpoint is anonymously usable, but the probes return responses such as 405/404 and the discovery sequence plus retry/backoff takes about 12 seconds.

   Relevant current source paths:

   • codex-rs/core/src/session/session.rs: session_init.auth_mcp awaits compute_auth_statuses() as part of thread/start.
   • codex-rs/rmcp-client/src/auth_status.rs: auth_status_before_discovery() skips discovery when either bearer_token_env_var is configured or the default headers contain Authorization.
   • The same file delegates discovery to rmcp::transport::AuthorizationManager.

   The static header therefore tells Codex that a bearer credential source is already configured, which bypasses OAuth capability discovery. The public Docs MCP currently tolerates this placeholder header and continues to serve anonymous requests.

   startup_timeout_sec does not help here because the delay happens in session_init.auth_mcp, before mcp_manager_init. Disabling shell_snapshot also has no effect.

   Scope / caveat

   This is a workaround, not the ideal client fix. It should only be used for an MCP endpoint that is known to work anonymously and tolerates this placeholder header. It should not be used to bypass authentication on a protected MCP server.

   The durable fix would be to avoid putting negative OAuth discovery for optional MCP servers on the synchronous thread/start / thread/resume path, or cache a negative discovery result. A first-class auth = "none" setting would also avoid using a placeholder header.
5. shurgalin commented on Jul 21, 2026

   

   shurgalin

   on Jul 21, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   Closing as completed: I verified the original user-visible regression is fixed in the current desktop build.

   Environment:

   • ChatGPT Desktop 26.715.70719 (build 5650)
   • bundled app-server 0.145.0-alpha.27
   • macOS 26.5.2 (25F84), Apple Silicon
   • openaiDeveloperDocs enabled

   After restarting the app, four existing threads resumed with thread/resume timings of 64 ms, 89 ms, 330 ms, and 344 ms. The previously affected thread resumed in 89 ms, and a Docs MCP search succeeded.

   One switch to the affected thread took about 5.85 seconds wall-clock, but the thread/resume RPC itself was 89 ms; the delay was outside that RPC while unrelated background app/list and mcpServer/resource/read requests were in flight. I do not treat that as a recurrence of this report's synchronous thread/resume regression.

   This matches the intended fix in #32825: avoid blocking thread startup on MCP OAuth discovery. If the remaining background delay becomes reproducible and user-visible, it should be tracked separately.
6. shurgalin

   closed this as completedon Jul 21, 2026