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

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

• #19070
• #18663
• #17860
• #17880

Powered by Codex Action

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:

``text
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 #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 #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 #31481 and #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.