›_ Codex Issues
Codex Issues / #29376

Desktop: remote MCP startup timeout blocks creating new conversation

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

Summary

When Codex Desktop starts a new local conversation/thread, a failing remote MCP server can block thread/start until the UI times out. In my case, an enabled remote MCP server caused thread creation to take about 40s. The UI showed timeout errors and the first message could not be sent. Disabling that MCP server and restarting Codex Desktop immediately fixed new conversation creation.

Environment

  • Codex Desktop on macOS
  • Codex Desktop version: 26.616.51431 (4212)
  • Chromium base: 149.0.7827.115
  • Local mode with an existing repo selected
  • Remote MCP server configured in ~/.codex/config.toml
  • The remote MCP URL was https://stitch.googleapis.com/mcp

Steps to reproduce

  1. Configure a remote MCP server that is unavailable or slow during auth/discovery/connection.
  2. Fully restart Codex Desktop.
  3. Open a new conversation in a local repo.
  4. Send the first message.

Actual behavior

  • The UI shows timeout errors such as:
  • Error creating task: Timeout
  • Error starting conversation: Timeout
  • Local logs show thread startup spending about 40s in the create-thread path before eventually emitting thread/started.
  • Representative log characteristics:
  • thread_start_create_thread duration_ms=40155
  • thread_start_total duration_ms=40161
  • session_init.auth_mcp attempts remote MCP OAuth discovery and fails/times out.
  • By the time thread/started is emitted, the UI has already timed out and the new conversation is not usable.

Expected behavior

A single optional MCP server should not block the core conversation/thread creation path. If a remote MCP server fails, Codex should degrade gracefully by marking that tool unavailable, loading/retrying it in the background, or using a shorter non-blocking timeout. The thread should still start and the user should still be able to send messages.

Workaround

Commenting out the problematic remote MCP server in ~/.codex/config.toml and restarting Codex Desktop restores new conversation creation.

Why this matters

MCP/connectors are optional extensions. A misconfigured, slow, or unreachable MCP server should not make the main Codex Desktop workflow unusable.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 2 months ago

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

  • #29321

Powered by Codex Action

TigerHix · 2 months ago

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

MugenLee · 1 month ago

+1，pls fix, This bug is stupid , and wasting my token!

wherewolf87 · 1 month ago

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.

OrezzerO · 1 month ago

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: https://github.com/openai/codex/issues/32654#issuecomment-4999764380

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.