codex-cli app-server (Linux) leaks chrome-devtools-mcp child trees on JSON-RPC transport close #24347

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   mcpIssues related to the use of model context protocol (MCP) serversIssues related to the use of model context protocol (MCP) servers

   performance

   on May 24, 2026
2. github-actions commented on May 24, 2026

   

   github-actionsbot

   on May 24, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Codex app appears to start duplicate MCP server processes across conversations #22992

   Powered by Codex Action
3. jshaofa-ui commented on May 24, 2026

   

   jshaofa-ui

   on May 24, 2026

   More actions

   Technical Proposal: Fix MCP Child Process Leak on Transport Close

   Service Match: A. MCP 集成服务
   Timeline: 2-3 days
   Competition: 1 comment

   Problem Analysis

   When JSON-RPC transport closes, the app-server fails to clean up child processes spawned by chrome-devtools-mcp, causing resource leaks and port conflicts.

   Proposed Fix

   impl JsonRpcTransport {
       async fn close(&mut self) -> Result<()> {
           // 1. Cancel all in-flight requests
           self.cancel_in_flight().await;
           
           // 2. Get list of MCP server child processes
           let mcp_children = self.mcp_registry.get_all_children().await;
           
           // 3. Gracefully terminate each MCP server
           for (server_id, child) in mcp_children {
               if let Err(e) = self.terminate_mcp_server(&server_id, child).await {
                   tracing::warn!(server_id, error = ?e, "Failed to terminate MCP server");
               }
           }
           
           // 4. Clean up registry
           self.mcp_registry.clear().await;
           
           // 5. Close transport
           self.inner.close().await
       }
       
       async fn terminate_mcp_server(&self, server_id: &str, child: &mut Child) -> Result<()> {
           let _ = child.start_kill(); // SIGTERM
           match tokio::time::timeout(Duration::from_secs(5), child.wait()).await {
               Ok(Ok(_)) => Ok(()),
               Ok(Err(e)) => Err(e.into()),
               Err(_) => {
                   let _ = child.kill(); // SIGKILL after timeout
                   child.wait().await.map_err(Into::into)
               }
           }
       }
   }

   Deliverables

   • Transport close handler with MCP server cleanup
   • Graceful termination with timeout and SIGKILL fallback
   • Unit tests for process lifecycle
   • Integration test verifying no leaked processes
4. yui-stingray commented on May 24, 2026

   

   yui-stingray

   on May 24, 2026

   More actions

   One concrete layer to inspect is the stdio MCP launcher rather than only the app-server connection gate. On current main (9f42c89):

   • codex-rs/app-server/src/lib.rs:902-914 handles TransportEvent::ConnectionClosed by removing the connection state, notifying outbound control, and calling processor.connection_closed(...); this is not itself the direct MCP child cleanup site.
   • That call currently goes through codex-rs/app-server/src/message_processor.rs:709-723: it shuts down the per-connection RPC gate and clears outgoing/fs/exec/thread bookkeeping. The thread side (codex-rs/app-server/src/request_processors/thread_processor.rs:2396-2408) removes the connection subscription and only finalizes stale bookkeeping if the thread was already removed; I do not see it directly submitting a thread/session shutdown there.
   • The stdio MCP path starts at codex-rs/codex-mcp/src/rmcp_client.rs:575-590, then the shared transport close path calls self.process.terminate().await in codex-rs/rmcp-client/src/stdio_server_launcher.rs:128-133.
   • On Unix, the local launcher puts the stdio server wrapper in its own process group (codex-rs/rmcp-client/src/stdio_server_launcher.rs:262-263), and the process-handle Drop path also terminates if close did not already run (:397-405). The executor-backed transport has a similar close-time terminate at codex-rs/rmcp-client/src/executor_process_transport.rs:159-162.
   • Existing cleanup coverage in codex-rs/rmcp-client/tests/process_group_cleanup.rs:98-130 and :133+ checks drop(client) / client.shutdown(), but I do not see a regression test for the app-server JSON-RPC connection-close path described in this report.

   So if this reproduces with chrome-devtools-mcp, the gap to verify may be whether app-server JSON-RPC connection close actually reaches the RmcpClient/stdio transport close or drop path for the session that owns the MCP server. The process-group cleanup primitive appears to exist; the uncertain part is whether this app-server close path drives it.
5. w2jmoe commented on May 27, 2026

   

   w2jmoe

   on May 27, 2026

   More actions

   This is a really good write-up 👀

   The interesting part is that the leak is not coming from model execution itself, but from transport/session lifecycle boundaries.

   Once the JSON-RPC channel closes, the runtime seems to lose ownership of the MCP child tree, so the process survives outside the original execution context.

   That’s a pretty nasty failure mode for long-running agent systems because the leak scales with tool-call count, not just session duration.

   The “youngest-per-server + grace window” reaper workaround is also clever 😊
   It basically recreates a missing lifecycle manager externally.

   Feels like MCP runtimes may eventually need explicit “capability ownership” tracking:
   which session spawned which process tree, who is responsible for teardown, and what happens during transport interruption / reconnect / partial failure.

   Otherwise these orphaned execution surfaces become surprisingly hard to reason about once multiple agents/tools/sessions coexist.