›_ Codex Issues
Codex Issues / #21346

ChatGPT auth mode: Cloudflare challenge on connectors/directory/list blocks all MCP tool calls from CLI

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

Summary

When using codex with auth_mode=chatgpt (the default for ChatGPT subscription users), all MCP tool calls fail because the CLI cannot pass Cloudflare's anti-bot challenge on the connectors/directory/list endpoint.

Environment

  • codex-cli 0.120.0 (installed via brew)
  • macOS, M1 Air
  • Auth: auth_mode=chatgpt in ~/.codex/auth.json
  • MCP servers configured in .codex/mcp_servers.json (local HTTP and stdio transports)

Reproduction

  1. Configure any MCP server in .codex/mcp_servers.json
  2. Ensure auth_mode=chatgpt in ~/.codex/auth.json
  3. Run codex mcp list — shows Auth: Unsupported for all servers
  4. Run any codex session that triggers MCP tool calls — all calls cancel with "user cancelled MCP tool call" (misleading; no actual user cancel)

Root Cause

Under ChatGPT auth, codex routes MCP tool authorization through https://chatgpt.com/backend-api/connectors/directory/list. This endpoint is behind Cloudflare's anti-bot challenge requiring JavaScript execution and cookies. The CLI HTTP client cannot pass this challenge, so the call fails, tool authorization never completes, and every MCP tool call gets internally cancelled.

Evidence from ~/.codex/log/codex-tui.log:

  • Cloudflare challenge HTML in response body: <noscript>Enable JavaScript and cookies to continue</noscript>
  • cf_chl_opt and _cf_chl_tk tokens present
  • Response is not valid JSON

Isolation

  • Direct codex exec PROBE (no MCP tool usage) works fine — API auth and chat path are healthy.
  • MCP servers respond correctly when probed directly via curl (tools/list in 150ms, tools/call in ~10s).
  • Setting tool_timeout_sec=60 in mcp_servers config does not change behavior — cancel happens before timeout.
  • auth_mode: chatgpt with fresh auth (last_refresh: 0.0 days) — auth itself is not stale.

Workaround

Switching to API key auth (OPENAI_API_KEY env var) bypasses the connectors directory entirely and MCP works. However, this bills against the API tier instead of the ChatGPT subscription, which is undesirable for subscribers.

Expected Behavior

ChatGPT auth mode should support MCP tool calls from the CLI, either by:

  • Handling the Cloudflare challenge (cookie jar, retry with JS challenge tokens)
  • Providing a flag to skip the connectors-directory routing for local MCP servers (no remote authorization needed)
  • Documenting that ChatGPT auth mode is incompatible with MCP usage from CLI

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 3 months ago

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

  • #20673

Powered by Codex Action

masakielastic · 3 months ago

I can reproduce a related Cloudflare challenge behavior from a Chromebook/Crostini Linux environment, and the result appears to be User-Agent dependent.

Environment / matrix:

  • macOS + home fiber: Codex works
  • Chromebook / Crostini Linux + home fiber: Codex is blocked
  • Chromebook / Crostini Linux + mobile tethering: Codex works
  • Same ChatGPT/Codex account

Diagnostic result from Chromebook / Crostini Linux on the home fiber connection:

  1. Request without an explicit browser-like User-Agent:
  • HTTP 403
  • cf-mitigated: challenge present
  1. Same request with a Chrome-like User-Agent:
  • HTTP 401 Unauthorized
  • cf-mitigated: challenge absent

The 401 response suggests that the request passed Cloudflare and reached the application layer, while the 403 response was a Cloudflare challenge.

This suggests that, at least in my environment, the block is not solely caused by TLS fingerprinting. HTTP-layer signals such as User-Agent appear to affect Cloudflare’s decision.

This may be relevant to ChatGPT auth mode / backend-api requests from the CLI, especially if some reqwest-based HTTP clients are using a default, missing, or non-browser-like User-Agent when calling chatgpt.com/backend-api/*.