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

I reproduced this independently with a macOS Codex 0.144.1 TUI connected over WSS to a Linux remote app-server.

All six remote MCP startup streams reached a terminal ready state, and a protocol relay confirmed that every status notification reached the macOS client, but the TUI remained frozen at 5/6. Launching the same remote session with an isolated client CODEX_HOME containing no local MCP entries completed immediately.

Root cause

The TUI seeds mcp_startup_expected_servers from the client's local config.mcp_servers, even for AppServerTarget::Remote. Completion requires every expected name to appear in the app-server status stream. A client-only MCP name can never be reported by the remote app-server, making the completion predicate permanently false.

This also explains why bubblewrap/zAppGuard and the individual MCP transports appeared suspicious but were not causal: the remote servers had already initialized and their terminal statuses were delivered.

Proposed patch

Commit: https://github.com/mjlbach/codex/commit/9431af2abc371603a62010168011ee4046f6c977

Compare: https://github.com/openai/codex/compare/main...mjlbach:codex:agent/fix-remote-mcp-startup

For remote workspaces, the patch uses the existing reported-server behavior (an empty configured expected set), so startup settles from the servers actually reported by the app-server. Embedded sessions retain the existing config-derived completeness guard. It intentionally does not forward client MCP overrides to the remote app-server.

<details>
<summary>Patch (code and regression test)</summary>

diff --git a/codex-rs/tui/src/app/app_server_events.rs b/codex-rs/tui/src/app/app_server_events.rs
index 06ed4320d8..5224093aa4 100644
--- a/codex-rs/tui/src/app/app_server_events.rs
+++ b/codex-rs/tui/src/app/app_server_events.rs
@@ -16,7 +16,17 @@ use codex_app_server_protocol::ServerNotification;
 use codex_app_server_protocol::ServerRequest;
 
 impl App {
-    pub(super) fn refresh_mcp_startup_expected_servers_from_config(&mut self) {
+    pub(super) fn refresh_mcp_startup_expected_servers(&mut self) {
+        // A remote app server owns its MCP configuration, so the TUI's local
+        // config cannot be used as the expected set for that startup round.
+        // An empty set lets the chat widget settle from the servers reported by
+        // the app server instead.
+        if self.app_server_target.uses_remote_workspace() {
+            self.chat_widget
+                .set_mcp_startup_expected_servers(std::iter::empty());
+            return;
+        }
+
         let enabled_config_mcp_servers: Vec<String> = self
             .config
             .mcp_servers
@@ -39,7 +49,7 @@ impl App {
                     skipped,
                     "app-server event consumer lagged; dropping ignored events"
                 );
-                self.refresh_mcp_startup_expected_servers_from_config();
+                self.refresh_mcp_startup_expected_servers();
                 self.chat_widget.finish_mcp_startup_after_lag();
             }
             AppServerEvent::ServerNotification(notification) => {
@@ -73,7 +83,7 @@ impl App {
                 }
             }
             ServerNotification::McpServerStatusUpdated(_) => {
-                self.refresh_mcp_startup_expected_servers_from_config();
+                self.refresh_mcp_startup_expected_servers();
             }
             ServerNotification::AccountRateLimitsUpdated(notification) => {
                 self.chat_widget
diff --git a/codex-rs/tui/src/app/tests.rs b/codex-rs/tui/src/app/tests.rs
index d8d63575bb..bb747d002b 100644
--- a/codex-rs/tui/src/app/tests.rs
+++ b/codex-rs/tui/src/app/tests.rs
@@ -3552,6 +3552,56 @@ async fn primary_thread_ignores_child_mcp_startup_notifications() {
     );
 }
 
+#[tokio::test]
+async fn remote_mcp_startup_ignores_local_expected_servers() {
+    let (mut app, _app_event_rx, _op_rx) = make_test_app_with_channels().await;
+    let local_only_config = toml::from_str::<toml::Value>("command = 'true'")
+        .expect("test MCP config should parse")
+        .try_into()
+        .expect("test MCP config should deserialize");
+    app.config
+        .mcp_servers
+        .set(std::collections::HashMap::from([(
+            "local-only".to_string(),
+            local_only_config,
+        )]))
+        .expect("test MCP servers should accept any configuration");
+    app.app_server_target = crate::AppServerTarget::Remote {
+        endpoint: codex_app_server_client::RemoteAppServerEndpoint::WebSocket {
+            websocket_url: "ws://remote.example/rpc".to_string(),
+            auth_token: None,
+        },
+    };
+
+    app.refresh_mcp_startup_expected_servers();
+
+    app.chat_widget.handle_server_notification(
+        ServerNotification::McpServerStatusUpdated(McpServerStatusUpdatedNotification {
+            thread_id: None,
+            name: "remote-only".to_string(),
+            status: McpServerStartupState::Starting,
+            error: None,
+            failure_reason: None,
+        }),
+        /*replay_kind*/ None,
+    );
+
+    assert!(app.chat_widget.is_task_running_for_test());
+
+    app.chat_widget.handle_server_notification(
+        ServerNotification::McpServerStatusUpdated(McpServerStatusUpdatedNotification {
+            thread_id: None,
+            name: "remote-only".to_string(),
+            status: McpServerStartupState::Ready,
+            error: None,
+            failure_reason: None,
+        }),
+        /*replay_kind*/ None,
+    );
+
+    assert!(!app.chat_widget.is_task_running_for_test());
+}
+
 #[tokio::test]
 async fn app_scoped_mcp_startup_notifications_do_not_render_in_active_thread() {
     let (mut app, mut app_event_rx, _op_rx) = make_test_app_with_channels().await;
diff --git a/codex-rs/tui/src/app/thread_routing.rs b/codex-rs/tui/src/app/thread_routing.rs
index b149fd53f3..5c3fefff6a 100644
--- a/codex-rs/tui/src/app/thread_routing.rs
+++ b/codex-rs/tui/src/app/thread_routing.rs
@@ -1316,7 +1316,7 @@ impl App {
         snapshot: ThreadEventSnapshot,
         resume_restored_queue: bool,
     ) {
-        self.refresh_mcp_startup_expected_servers_from_config();
+        self.refresh_mcp_startup_expected_servers();
         let should_buffer_replay = !snapshot.turns.is_empty() || !snapshot.events.is_empty();
         if should_buffer_replay {
             self.app_event_tx

</details>

Validation

• just fmt
• just test -p codex-tui
• just fix -p codex-tui

The full codex-tui suite and required Clippy autofix completed successfully.

I can reproduce this locally with Codex 0.147.0 on both the client and the NAS.

Reproduction

I start the NAS app-server and expose it through an SSH local forward:

ssh -N -L 4500:127.0.0.1:4500 <nas-user>@<nas-host>
codex app-server --listen ws://127.0.0.1:4500

Then I attach the local TUI:

codex --remote ws://127.0.0.1:4500 resume

The local client has these enabled MCP entries:

• ai-drawio
• codegraph
• lean-lsp
• node_repl
• wolframAI
• github
• openaiDeveloperDocs

The NAS app-server has only:

• brave-search
• github

The SSH tunnel and WebSocket connection are healthy: initialize, thread resume, and the app-server RPCs complete successfully. The NAS reports brave-search and github through starting -> ready, but the TUI remains stuck at Loading MCP indefinitely because the client-only MCP names never appear in the remote status stream.

Disabling the local-only MCP entries with -c mcp_servers.<name>.enabled=false allows the remote TUI to start. This reproduces the same local-vs-remote expected-server mismatch described in the root-cause analysis above.

The proposed fix in Avoid local MCP gating for remote startup also appears to address this exact reproduction.