[Windows 26.707.31428 trace] MCP OAuth secrets-store lock blocks thread/start for 60s #32799

Environment

• Current Codex Desktop package: OpenAI.Codex_26.707.8479.0_x64__2p2nqsd0c76g0
• Current installed version: 26.707.8479.0
• Native trace reproducing the primary thread/start failure recorded client version: 26.707.31428
• Platform: Microsoft Windows NT 10.0.26200.0 x64
• Subscription: not programmatically verified during this diagnostic session
• MCP configuration at current inspection: 36 enabled entries, including 13 remote HTTP servers

Summary

Codex Desktop can block new-task creation while optional remote MCP clients wait on the shared encrypted OAuth secrets-store lock. Native app-server traces show thread/start entering session_init.mcp_manager_init, then several MCP clients independently waiting 60 seconds for the same lock and failing to read tokens.

The Desktop UI subsequently presents errors including:

Error creating task: Timeout
Error starting conversation: Timeout

A related failure has also appeared as:

failed to start turn: internal error, agent loop died unexpectedly

The evidence supports lock contention on the critical thread-start path. It does not yet identify which process originally retained the lock, so this report does not claim a definitive lock-holder root cause.

Native trace evidence

During a failing new-task request, the native trace path was:

app_server.request rpc.method="thread/start"
  -> app_server.thread_start.create_thread
  -> thread_spawn
  -> session_init
  -> session_init.mcp_manager_init
  -> make_rmcp_client

Six enabled remote MCP clients then emitted the same failure at approximately the same time:

failed to read tokens for server `<redacted-remote-mcp>`:
timed out after 60s waiting for MCP OAuth encrypted secrets
aggregate-store lock <redacted-user-home>/.codex/mcp-oauth-locks/secrets-store.lock

The server names are omitted because the specific integrations are not material to the shared-lock failure. They can be supplied privately if needed.

A later trace on the same machine recorded the same shared lock affecting both initialization paths for another optional remote MCP:

session_init.mcp_manager_init
  -> start_server_task
  -> initialize
  -> timed out after 60s waiting for the OAuth encrypted secrets-store lock

session_init.auth_mcp
  -> failed to determine auth status
  -> timed out after 60s waiting for the same lock

That later event occurred while initializing an agent session, demonstrating that the contention can affect both top-level task creation and nested session startup.

Reproduction conditions

The failure is intermittent, but the observed conditions are:

1. Configure multiple enabled remote HTTP MCP servers that use Codex's encrypted OAuth/token store.
2. Start a new Desktop task, or initialize another agent session, while another process/session is updating or retaining the shared OAuth store state.
3. Observe thread/start enter MCP authentication and manager initialization.
4. Multiple optional remote MCP clients wait on the same aggregate-store lock.
5. The wait reaches 60 seconds and the Desktop task-creation request exceeds the UI's usable timeout.
6. The message does not submit and the sidebar may retain failed New task entries.

Expected behavior

• Optional MCP authentication must not block the core thread/start path for 60 seconds.
• A busy or stale OAuth-store lock should fail fast, retry in the background with bounded backoff, or mark only the affected MCP unavailable.
• A task should still be created and remain usable when one or more optional MCP servers cannot read auth state.
• Lock diagnostics should identify the holder or owning process sufficiently for safe recovery.
• Concurrent task/subagent initialization should not serialize into a global failure behind one OAuth lock.

Actual behavior

• Several optional remote MCPs block concurrently on one OAuth aggregate-store lock.
• Each reports a 60-second timeout while thread/start is still initializing.
• The Desktop UI reports task/conversation timeout and the first message cannot be submitted.
• Similar contention recurs during nested agent-session initialization.

Related reports

• Desktop: remote MCP startup timeout blocks creating new conversation #29376
• [Windows] Codex App times out when creating a task or starting a conversation #31762
• First-turn API call blocks until pending MCP tools/list times out #19556
• Codex Desktop: composer submit times out after stale conversation state accumulates; restart clears it #23644

The key additional evidence here is the explicit native trace showing several MCP clients and both mcp_manager_init and auth_mcp blocked by the same encrypted secrets-store lock.

Privacy and diagnostic availability

All OAuth values, server-specific credentials, local usernames, private paths, request IDs, thread IDs, workspace names, and unrelated log content have been removed. Sanitized trace excerpts can be provided privately if a maintainer requests them.