›_ Codex Issues
Codex Issues / #31193

codex mcp-server: transient "Auth(AuthorizationRequired)" when spawning multiple concurrent stdio server instances

Resolved 💬 3 comments Opened Jul 5, 2026 by ryangu00 Closed Aug 26, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Running codex mcp-server (ChatGPT-subscription login, no API key) as a stdio MCP server, spawned as independent child processes (each invocation does spawn("codex", ["mcp-server"]), fresh process per task, no shared state between them), I observe intermittent transport failures:

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

Observed evidence (from real logs tonight, timestamps included)

Two codex mcp-server processes were spawned within the same second, dispatched from two separate tools/call requests issued almost simultaneously:

  • Process A: failed at 2026-07-05T21:06:33.754284Z with the error above
  • Process B: succeeded, dispatched at essentially the same wall-clock moment

Across one evening of usage I logged 4 failures out of 23 total codex mcp-server invocations (17.4%), so this is not a rare one-off.

What I've ruled out

  • Not a bug in my client: my stdio client is a minimal NDJSON wrapper (initialize → notifications/initialized → tools/call), it does not touch auth at all.
  • Not a permanently-expired session: codex login status and codex doctor both show a healthy, currently-valid ChatGPT auth (stored ChatGPT tokens: true) immediately after the failures.
  • codex doctor shows the ChatGPT backend auth path is a WebSocket connection (wss://chatgpt.com/backend-api/..., handshake HTTP 101 Switching Protocols) — this may be relevant to why concurrent process spawns racing for auth could produce a transient channel-closed error.

Environment

  • codex-cli 0.142.5 (installed via brew)
  • macOS 26.5.1 (Apple Silicon)
  • Auth mode: ChatGPT subscription (not API key)

Question for maintainers

Is there a known race condition when multiple codex mcp-server processes are spawned concurrently and each performs its own auth handshake against the shared ChatGPT session/token store? Is there a recommended way to avoid this (e.g., serializing server startup, a shared auth-refresh lock, or a codex config flag to increase auth-handshake retry tolerance) rather than the caller having to retry externally?

I don't have a minimal concurrent-only repro isolated from my larger workflow yet — happy to try to produce one if useful. Filing this now with the real evidence I have, since the failure mode is disruptive enough (17% of invocations) that it seemed worth reporting even without a fully isolated repro.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

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

  • #31194

Powered by Codex Action

ryangu00 · 1 month ago

Additional data point (originally filed as a separate issue, #31194, closing that one as a duplicate of this one per the bot's correct flag):

The same error also reproduces on a single, isolated, non-concurrent codex mcp-server invocation — nothing else running codex at the same time:

  • Attempt 1: failed immediately with the same Auth(AuthorizationRequired) error.
  • Attempt 2 (fresh process, ~3s later): succeeded normally.

So concurrency (multiple codex mcp-server processes spawned at once, as in the original report above) is not a necessary condition for this failure — it may just be one factor that increases likelihood. This points toward a general auth-handshake reliability issue in mcp-server mode's ChatGPT-auth path (which codex doctor shows is a WebSocket connection to wss://chatgpt.com/backend-api/...), rather than purely a multi-process race.

Measured frequency across one evening: 4 failures out of 23 total codex mcp-server invocations (17.4%), across both the concurrent and isolated-single-call cases combined.

etraut-openai contributor · 2 days ago

Note: We've announced that the mcp-server is deprecated and will be removed in a future release. We recommend using the app server interface instead. We won't be prioritizing any bug fixes in the mcp-server, so I'm going to close this issue.