0.117.0 regression: default tui_app_server hides MCP startup failures/warnings on startup

What version of Codex CLI is running?

codex-cli 0.117.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.4 xhigh

What platform is your computer?

Windows 10 21H2 x64

What terminal emulator and version are you using (if applicable)?

Windows Terminal running PowerShell 7.x

What issue are you seeing?

In Codex CLI 0.117.0, MCP startup failures and warnings are not shown during cold start in the default app-server-backed TUI path.

I can reproduce this by intentionally breaking one enabled stdio MCP server so it fails during the initialize/handshake phase. When Codex is started normally with:

codex

the terminal reaches the normal input prompt without showing any visible MCP startup warning or failure text.

The same configuration started with:

codex --disable tui_app_server

does show the expected startup failure messages, for example:

MCP client for 'example-stdio' failed to start: MCP startup failed: handshaking with MCP server failed: connection closed: initialize response
MCP startup incomplete (failed: example-stdio)

So this appears to be a visibility regression in the default app-server-backed TUI path, not that MCP startup has stopped happening.

This is operationally significant because startup-health checks, restart tooling, or users relying on visible boot diagnostics can incorrectly conclude that Codex started cleanly when an enabled MCP server actually failed at startup.

What steps can reproduce the bug?

1. Configure an enabled stdio MCP server that will fail during initialize/handshake. For example:

[mcp_servers.example-stdio]
command = "cmd"
args = ["/c", "echo nope"]

This starts a process successfully but does not speak MCP over stdio.

1. Start Codex normally:

codex

1. Observe that the default startup path reaches the normal prompt without showing the MCP startup failure/warning text.

1. Start Codex with the legacy TUI path:

codex --disable tui_app_server

1. Observe that the same broken MCP now produces visible startup warnings/errors such as:

MCP client for 'example-stdio' failed to start: MCP startup failed: handshaking with MCP server failed: connection closed: initialize response
MCP startup incomplete (failed: example-stdio)

1. Optional sanity check: run /mcp after normal startup and confirm the broken MCP is still configured.

What is the expected behavior?

If an enabled MCP server fails during startup, the default codex startup path should surface that failure clearly in the terminal during cold start, similar to the legacy TUI path.

At minimum, startup warnings such as MCP handshake failures and MCP startup incomplete should remain visible in the default app-server-backed TUI so users can tell whether Codex actually started cleanly.

Additional information

This looks like a visibility/reporting regression in the default app-server-backed TUI path introduced in 0.117.0, not a lazy-loading change.

I verified that:

• This was tested as a direct A/B on the same machine with the same Codex version, the same config, and the same intentionally broken stdio MCP server. The only change was codex vs codex --disable tui_app_server.
• codex --disable tui_app_server shows the startup failures immediately.
• The default codex path does not show them.
• /mcp still shows the broken MCP as configured after normal startup.

There is also a related open 0.117.0 app-server TUI rendering regression:

• #15984 - 0.117.0 regression: UserPromptSubmit hook output is not rendered in TUI/app-server path