TUI hangs forever at 'Loading MCP (x/y)' when 'resume --remote' has -c mcp_servers.* overrides the app-server doesn't have

What version of Codex CLI is running?

0.144.1 (npm) — also reproduced on 0.138.0

What subscription do you have?

n/a — the hang happens during MCP loading, before any model/auth interaction

Which model were you using?

n/a

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64 (Windows 11 Pro)

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

Windows Terminal / plain cmd.exe (reproduces in both)

Codex doctor report

not available

What issue are you seeing?

codex resume --remote <ws-url> <thread-id> hangs forever at Loading MCP (x/y) when the client command carries -c mcp_servers.* config overrides that the app-server it attaches to was not started with. The TUI never becomes usable; it stays on the MCP loading indicator indefinitely (waited 10+ minutes).

Notes from debugging:

• The configured MCP server itself is healthy (a local streamable-HTTP server that answers in milliseconds). While the TUI is frozen, no TCP connection is ever opened to the configured MCP URL, so it is not a slow/unresponsive server — it looks like a deadlock in the remote-attach handshake around the config/MCP sync.
• RUST_LOG=codex_core=debug,rmcp=trace on the app-server shows nothing relevant after the attach (only unrelated plugin-manifest warnings at startup).

What steps can reproduce the bug?

Using any existing thread id (create one with a plain codex session first):

Terminal A — start an app-server without the MCP override:

codex -c check_for_update_on_startup=false app-server --listen ws://127.0.0.1:7777

Terminal B — attach to it with an MCP override on the client:

codex resume --remote ws://127.0.0.1:7777 <thread-id> -c mcp_servers.example.url=http://127.0.0.1:64442/stream -c mcp_servers.example.tool_timeout_sec=3600 -c mcp_servers.example.http_headers.X_AUTH=sometoken

→ stuck at Loading MCP (x/y) forever.

Full matrix tested (same thread, same machine):

| app-server flags | resume client flags | result |
|---|---|---|
| none | none | ✅ works |
| none | mcp_servers.* overrides | ❌ frozen at Loading MCP |
| mcp_servers.* overrides | none | ✅ works (and the MCP server's tools are available in the session) |
| mcp_servers.* overrides | same overrides | ✅ works |

A plain local codex resume <thread-id> (no --remote) with the exact same mcp_servers.* overrides also works fine — the hang is specific to remote attach.

What is the expected behavior?

Client-side mcp_servers.* overrides on resume --remote should either be applied to the session, or be ignored with a warning — not deadlock the TUI at MCP loading.

Additional information

Found via an IDE integration that spawns the app-server itself and attaches a TUI with an injected per-session MCP server config; the repro above is fully standalone (no IDE involved). Happy to run further diagnostics on request.