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

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
• Current-build observation: after rebooting into 26.707.8479.0, the same OAuth-lock timeout has not yet recurred in a controlled observation; recurrence on the current build remains unverified
• 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

On client version 26.707.31428, Codex Desktop blocked new-task creation while optional remote MCP clients waited 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 machine is now running 26.707.8479.0, where this exact timeout has not yet been re-observed after reboot, so the report does not claim confirmed current-build recurrence.

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

• #29376
• #31762
• #19556
• #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.