### Summary Codex CLI frequently appears frozen at startup on: `Starting MCP servers (2/3): codex_apps` ### Environment - Codex CLI: `0.125.0` - OS: macOS `26.3 (25D125)` - Host: Apple Silicon - Date observed: 2026-04-29 ### Repro 1. Start `codex` in terminal. 2. Observe startup status line. 3. It often stays on `Starting MCP servers (2/3): codex_apps` for a long time (minutes in user sessions). ### Expected Startup should either: - complete quickly, or - fail fast with an explicit actionable

Potential duplicates detected. Please review them and close your issue if it is a duplicate. - #19284 - #18792 - #19576 *Powered by [Codex Action](https://github.com/openai/codex-action)*

Codex hangs on startup at 'Starting MCP servers (2/3): codex_apps'

Open 💬 2 comments Opened Apr 29, 2026 by majiayu000

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Codex CLI frequently appears frozen at startup on:
Starting MCP servers (2/3): codex_apps

Environment

Codex CLI: 0.125.0
OS: macOS 26.3 (25D125)
Host: Apple Silicon
Date observed: 2026-04-29

Repro

Start codex in terminal.
Observe startup status line.
It often stays on Starting MCP servers (2/3): codex_apps for a long time (minutes in user sessions).

Expected

Startup should either:

complete quickly, or
fail fast with an explicit actionable error (network/auth/backend status) instead of appearing hung.

Actual

The UI appears stuck on codex_apps startup for a long time.

Evidence from local logs

From ~/.codex/log/codex-tui.log:

2026-04-27T07:24:29.633581Z

failed to force-refresh tools for MCP server 'codex_apps' ... MCP startup failed: timed out handshaking with MCP server after 30s

2026-04-28T08:28:02.773239Z

failed to force-refresh tools for MCP server 'codex_apps' ... HTTP request failed ... url (https://chatgpt.com/backend-api/wham/apps)

2026-04-22T07:19:09.903833Z (and multiple similar entries)

failed to force-refresh tools for MCP server 'codex_apps' ... error sending request for url (https://chatgpt.com/backend-api/wham/apps)

Notes

This looks like connector startup / handshake resilience issue.
Even when eventual fallback may happen, UX currently resembles a freeze.

Suggested fix

Add clear startup timeout UX for codex_apps with visible reason.
Degrade gracefully: continue startup with cached tools and explicit warning banner.
Include retry backoff with user-visible status (attempt count + elapsed time).

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 4 months ago

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

#19284
#18792
#19576

Powered by Codex Action

keepgoodfeeling · 1 month ago

Still reproducible on Codex CLI 0.145.0 (Linux x86_64).

Local diagnostics show that codex_apps initialization encountered a retryable transport error:

connection closed before message completed

The first initialization exceeded the generated startup_timeout_sec = 30, but a background retry succeeded approximately 32 seconds after startup. As a result, the TUI reported incomplete MCP startup even though codex_apps became available shortly afterward.

The local codex_apps tool/server metadata caches were already populated. A more resilient startup strategy would be:

start immediately from valid cached tool metadata;
refresh the live MCP connection in the background;
show a non-blocking warning if refresh fails;
retry the live connection when an App tool is actually invoked.

This would prevent transient connector transport failures from delaying unrelated local coding sessions.