codex mcp-server: same "Auth(AuthorizationRequired)" transient failure reproduces on a single, non-concurrent invocation

Summary

Follow-up to a related report (#31193) about codex mcp-server transient auth failures. That report focused on a case where the failure correlated with concurrent process spawns. This issue documents that the same failure also reproduces on a single, isolated, non-concurrent invocation, so concurrency is not a necessary condition — it may just be one factor that increases likelihood.

ERROR rmcp::transport::worker: worker quit with fatal: Transport channel closed, when Auth(AuthorizationRequired)

Repro

A single codex mcp-server process, spawned in isolation (nothing else invoking codex at the same time), given a trivial one-line prompt task:

• Attempt 1: failed immediately with the error above.
• Attempt 2 (fresh process, ~3s later): succeeded normally, correct output returned.

Environment

• codex-cli 0.142.5 (installed via brew)
• macOS 26.5.1 (Apple Silicon)
• Auth mode: ChatGPT subscription (codex login status → "Logged in using ChatGPT"; codex doctor shows stored ChatGPT tokens: true, auth healthy both before and after the failure)
• codex doctor shows the ChatGPT backend connection is a WebSocket (wss://chatgpt.com/backend-api/..., HTTP 101 Switching Protocols handshake), which may be relevant context for why a single connection attempt could transiently fail auth even with a valid stored session.

Measured frequency

Across one evening of codex mcp-server usage (23 total invocations via a simple stdio wrapper), this exact error occurred 4 times (17.4%) — including the isolated single-call case described here. This is frequent enough to be disruptive for any workflow that dispatches tasks to codex mcp-server programmatically, since a caller currently has no way to distinguish this from a real, non-retryable failure without inspecting stderr for this specific string.

What would help

• Confirmation of whether this is a known issue in the ChatGPT-auth handshake path for mcp-server mode.
• If it's expected to be transient, an internal retry/backoff before the worker gives up and closes the transport, so callers don't need to implement their own external retry-on-this-string-match workaround (which is what I've had to do in the meantime).

Filing as a separate issue from #31193 since this reproduces without the concurrency factor, indicating a broader single-call reliability issue in the auth handshake rather than purely a multi-process race.