Desktop: remote MCP startup timeout blocks creating new conversation #29376

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

   connectivityIssues involving networking or endpoint connectivity problems (disconnections)Issues involving networking or endpoint connectivity problems (disconnections)

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

   on Jun 22, 2026
2. github-actions commented on Jun 22, 2026

   

   github-actionsBot

   on Jun 22, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • MCP startup should not block tool listing or thread startup #29321

   Powered by Codex Action

   👍React with 👍1Reacted by Hello-Mugen
3. TigerHix commented on Jun 23, 2026

   

   TigerHix

   on Jun 23, 2026

   More actions

   Confirmed. After removing the stale MCP server I can now create chats again.This bug is stupid af

   👍React with 👍1Reacted by Hello-Mugen
4. Hello-Mugen commented on Jun 29, 2026

   

   Hello-Mugen

   on Jun 29, 2026

   More actions

   +1，pls fix, This bug is stupid , and wasting my token!
5. wherewolf87 commented on Jul 13, 2026

   

   wherewolf87

   on Jul 13, 2026

   Last edited by wherewolf87

   More actions

   I captured native Windows app-server trace evidence for the same failure family and filed the sanitized details in #32799.

   The verified failing trace was emitted by client version 26.707.31428. After rebooting into the currently installed 26.707.8479.0, this exact OAuth-lock timeout has not yet recurred in a controlled observation, so current-build recurrence remains unverified.

   During a failing thread/start, the trace entered session_init.mcp_manager_init. Six enabled remote MCP clients then failed at approximately the same time with:

   timed out after 60s waiting for MCP OAuth encrypted secrets aggregate-store lock
   

   The shared lock was the Codex MCP OAuth secrets-store.lock; the user path, server names, request IDs, and credentials were removed from the public report. A later trace showed both start_server_task -> initialize and session_init.auth_mcp timing out after 60 seconds on the same lock during another agent-session initialization.

   This directly supports keeping optional remote MCP auth off the critical thread/start path, or degrading only the affected MCP instead of failing task creation.
6. OrezzerO commented on Jul 17, 2026

   

   OrezzerO

   on Jul 17, 2026

   More actions

   I found a concrete variant of this issue with the first-party openaiDeveloperDocs MCP on Codex CLI 0.144.5.

   The thread/start timeline showed about 12 seconds inside session_init.auth_mcp before the actual MCP initialize phase. The cause was eager OAuth discovery against an endpoint that is anonymously usable. The discovery path probed the MCP URL and multiple /.well-known/... endpoints, received 405/404 responses, and the sequence plus retry/backoff blocked /new.

   For this specific anonymous endpoint, the following scoped workaround reduced /new from about 15 seconds to 2.96 seconds while preserving all 5 Docs MCP tools and successful search_openai_docs calls:

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

   Why: codex-rs/rmcp-client/src/auth_status.rs skips OAuth discovery when auth_status_before_discovery() sees an Authorization header. The public Docs MCP currently tolerates the placeholder header. startup_timeout_sec has no effect because session_init.auth_mcp runs before mcp_manager_init.

   Full evidence and caveats: #32654 (comment)

   This is not a general solution for protected MCP servers. It reinforces the issue's proposed durable fix: optional MCP auth discovery should not block thread/start; negative discovery should be cached or an explicit no-auth mode should be available.
7. faelp22 commented on Sep 17, 2026

   

   faelp22

   on Sep 17, 2026

   More actions

   Additional observation: Codex should probably isolate MCP failures from the conversation lifecycle

   Although I was able to fix the immediate problem by updating my own MCP server, I think there is still an important Codex Desktop robustness issue here.

   In my case, I had access to the MCP server source code and was able to:

   • inspect the server logs;
   • identify the MCP Java SDK 2.0.0 Stateless handler bug;
   • update it to MCP Java SDK 2.0.1;
   • adjust the advertised MCP capabilities;
   • redeploy the server.

   After doing that, Codex stopped freezing and even previously stuck conversations became usable again.

   However, most Codex users will not necessarily have control over the MCP server they are using.

   The MCP server could be:

   • a third-party hosted service;
   • a corporate/internal MCP managed by another team;
   • a vendor MCP server;
   • an outdated server implementation;
   • temporarily unavailable;
   • returning an invalid MCP/JSON-RPC response;
   • returning an unexpected HTTP 4xx/5xx response.

   In those situations, the Codex Desktop client should ideally protect the main conversation lifecycle from the MCP failure.

   The failure mode I observed was approximately:

   Codex Desktop
         |
         | MCP capability probe
         v
   Remote MCP server
         |
         | unexpected HTTP 500
         v
   Codex conversation remains in busy/streaming state
         |
         v
   follow-up messages cannot be sent
   

   I think the preferable behavior would be something closer to:

   Codex Desktop
         |
         | MCP request
         v
   Remote MCP server
         |
         | error / timeout / invalid response
         v
   Codex marks that MCP server/tool as unavailable
         |
         +--> surfaces an MCP error to the user
         |
         +--> resets the current turn state
         |
         +--> keeps the conversation usable
   

   In other words, an external MCP server failure should probably not be able to leave the entire conversation permanently stuck in a streaming/busy state.

   Some possible defensive behaviors on the Codex side could be:

   • treat MCP initialization/capability-discovery failures independently from the main conversation state;
   • ensure the turn is always transitioned out of streaming if an MCP request fails;
   • enforce a timeout around MCP initialization and tool/capability requests;
   • gracefully handle HTTP 4xx/5xx responses;
   • gracefully handle malformed or unexpected JSON-RPC responses;
   • mark the affected MCP server as degraded/unavailable;
   • allow retry/reconnect of the MCP server independently from the chat;
   • keep the composer enabled after the failed turn has been finalized;
   • surface the actual MCP error instead of leaving the UI spinner running indefinitely.

   This seems especially important because an MCP client cannot assume that every connected MCP server is perfectly implemented or fully up to date.

   There is also a related report in #44102 #44590 describing a similar principle: a failing remote MCP server should not block the core Codex Desktop conversation/thread workflow.

   In my case, fixing the MCP server solved the immediate problem, but I believe Codex Desktop could still benefit from defensive isolation so the same class of MCP failure does not make the entire chat unusable for users who cannot modify the remote MCP server.
8. caduosmarini commented on Sep 28, 2026

   

   caduosmarini

   on Sep 28, 2026

   More actions

   Additional Windows Desktop reproduction on Codex 26.924.2738.0 (Windows 11, build 26200, x64).

   Enabling a plugin that bundles nine optional remote HTTP MCP servers made new local chats remain at “Starting your task” and show “It is taking longer than normal to start your thread” after the first message. The rest of the desktop experience also became unreliable while these servers initialized.

   Sanitized observations from local desktop logs on September 27–28, 2026:

   • Across repeated thread starts, the nine servers produced 357 failed startup-status events: 212 not logged in and 145 timed out after 30 seconds. There were 87 cancelled events and no ready event for these servers. These are log events across multiple threads, not independent connection attempts.
   • The local app server also logged failed to read OAuth tokens from keyring: failed to load MCP OAuth tokens from encrypted storage.
   • During the same startup activity, the app server logged workspace routing discovery timed out.
   • All nine HTTPS endpoints were reachable from this computer and responded quickly to an unauthenticated GET; an unauthenticated MCP POST received the expected 401 with WWW-Authenticate. This makes a simple network outage less likely.

   An old encrypted MCP token file had been imported into this Windows installation, so a mismatch with local credential storage is plausible, but I have not proven the underlying decryption failure. I also have no trace showing the 60-second secrets-store lock described in #32799; this report is about the user-visible effect of optional MCP authentication/startup failures on chat startup.

   Expected: failure of optional MCP servers should mark those integrations unavailable while the chat starts and remains usable. The UI should report the MCP failures without making the whole task appear stuck.

   I removed the affected plugin to continue using Codex. I can provide redacted log excerpts privately if maintainers need them. No tokens, private URLs, or local paths are included here.