Long-lived ChatGPT-auth CLI sessions can stall on codex_apps while fresh sessions load instantly (403 Cloudflare HTML on connectors/apps discovery) #19284

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   connectivityIssues involving networking or endpoint connectivity problems (disconnections)Issues involving networking or endpoint connectivity problems (disconnections)

   authIssues related to authentication and accountsIssues related to authentication and accounts

   on Apr 24, 2026
2. github-actions commented on Apr 24, 2026

   

   github-actionsbot

   on Apr 24, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • MCP/connectors discovery fails with 403 Forbidden Cloudflare challenge, despite successful ChatGPT login #19070
   • Codex-cli lag on every prompt when "background" apps/plugins discovery requests not disabled #18663
   • Linux/WSL2: Cloudflare 403 blocks all chatgpt.com API requests — rustls TLS fingerprint detected as bot while macOS native-tls works fine on same network #17860
   • [Bug] Recursive Context Poisoning (Cloudflare/WAF) triggering persistent History Loss and False Rate Limits #17880

   Powered by Codex Action
3. etraut-openai

   removed

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   on Apr 24, 2026
4. qixuancao commented on Jul 15, 2026

   

   qixuancao

   on Jul 15, 2026

   More actions

   Additional controlled evidence from codex-cli 0.144.4 on native Ubuntu 26.04 x86_64 (ChatGPT auth).

   Original failure

   • The default TUI consistently reported:

     MCP client for codex_apps failed to start: timed out awaiting tools/list after 30s
     

   • Core Codex/model calls continued to work, and -c features.apps=false removed the startup delay, so the repository and core model path were not involved.

   • During the failure window, a separate app/list { forceRefetch: true } diagnostic returned JSON-RPC -32603 with an HTTP 403 Cloudflare Managed Challenge (Enable JavaScript and cookies to continue). A clean temporary CODEX_HOME did the same.

   • A same-account/same-egress Mac control using the real Codex Desktop identity succeeded. The client-identity experiment below shows that both the clean-home probe and this Mac/Linux comparison were confounded by clientInfo.name; neither should be treated as proof of a Linux TLS-only problem or of a stale-home problem.

   • The failing shared server was an unmanaged, code-mode-host-launched process (codex -c features.code_mode_host=true app-server --listen unix://). codex app-server daemon stop explicitly reported that it was not daemon-managed.

   Recovery after a Codex-only restart

   I terminated all Codex/TUI/app-server processes and their MCP children, without rebooting Ubuntu. I then started a CLI-managed app-server with codex app-server daemon start.

   Afterward:

   • a standard codex --no-alt-screen TUI stayed up for more than 35 seconds without the warning;
   • /mcp loaded the Apps tool inventory;
   • a real read-only codex_apps.gmail.get_profile call completed successfully (no profile data was retained or included here).

   This proves the failure is recoverable on the same Linux binary. The restart also changed the app-server launch/identity path (unmanaged code-mode-host server to CLI-managed daemon), so this is not evidence that clearing memory alone fixed it.

   Reproducible clientInfo.name / generated User-Agent A/B

   After recovery, I used a small stdio app-server client. Every run used the same Linux host, account, token, network path, clean temporary CODEX_HOME, binary, request (app/list with forceRefetch: true), and platformFamily=unix / platformOs=linux. Only initialize.params.clientInfo.name changed.

   Alternating A/B results:

   clientInfo.name	Result	Repeats	Typical latency
   codex_cli	HTTP 403 Managed Challenge	3/3	0.66-0.74 s
   codex_vscode	Success	3/3	3.4-14.5 s

   Additional checks:

   clientInfo.name	Result
   codex_cli_rs	Success
   Codex Desktop	Success
   codex_desktop	HTTP 403 Managed Challenge
   codex-tui	HTTP 403 Managed Challenge
   codex_tui	HTTP 403 Managed Challenge
   my_product (the public app-server manual's example name)	HTTP 403 Managed Challenge

   The initialize response confirms that the name is embedded in the generated upstream User-Agent, for example:

   codex_cli/0.144.4 (Ubuntu 26.4.0; x86_64) ...
   codex_vscode/0.144.4 (Ubuntu 26.4.0; x86_64) ...
   

   This does not establish whether the decision is an intended known-client allowlist, a WAF rule, or another server-side policy. It does establish that, on the same Linux host and at the same time, app/list is sensitive to the client identity/derived User-Agent rather than Linux/TLS alone. If arbitrary clients are not allowed to access Apps, the app-server should return an explicit authorization/unsupported-client error rather than a Cloudflare browser challenge.

   Highly relevant fixes already merged after 0.144.4

   Public source explains why the launch/identity change matters:

   • app-server initialization copies clientInfo.name into the process originator and generated User-Agent;
   • PR fix: forward originator to Codex Apps MCP #31481 / commit b58952b0fa889f7958af37d057b521f3fdab4d3c is titled "fix: forward originator to Codex Apps MCP". Its description says production showed the downstream Apps MCP identity being lost as CODEX_UNKNOWN_DEFAULT;
   • PR fix(mcp): default Apps product SKU to codex #31803 / commit 23a09eb3c3d00ab2a2b96b69aa81454a0a88cca1 adds a default X-OpenAI-Product-Sku: codex header for Apps;
   • neither commit is present in the rust-v0.144.4 tag used here.

   This makes missing/misforwarded Apps request identity the strongest current explanation for the original 0.144.4 failure and for why switching from an unmanaged code-mode-host app-server to a CLI-managed daemon restored it. The Cloudflare policy is server-side, so I cannot prove from public source which header or classification produced the challenge.

   The direct app/list 403 and the TUI's final tools/list timeout were observed in the same Apps failure investigation, but I have not proved they are the same HTTP request or retry chain.

   Related: #17860. That issue's Linux/rustls-only hypothesis is not sufficient to explain the identity-dependent A/B above.

   Suggested fixes:

   1. Backport or release the originator/SKU fixes from fix: forward originator to Codex Apps MCP #31481 and fix(mcp): default Apps product SKU to codex #31803 to the stable CLI.
   2. Preserve actionable Apps/Connectors failure details in diagnostics instead of only reporting a 30-second tools/list timeout when the underlying cause is available.
   3. Document and validate accepted clientInfo.name values for Apps, or make the documented generic app-server client path work consistently.
   4. Add an Apps/Connectors probe to codex doctor so this failure is distinguishable from core auth/model health.

   I intentionally did not attach raw auth files, tokens, account identifiers, IP addresses, or the full Cloudflare HTML response.