MCP server processes orphaned when parent (Claude CLI) dies — 4GB memory leak

[dalegass]

Problem

When XcodeBuildMCP is launched as an MCP server via npm exec xcodebuildmcp@latest mcp (as Claude Code does), the process persists indefinitely after the parent process exits. Each orphaned instance consumes up to 4GB of resident memory.

This is especially painful when running multiple Claude Code sessions — orphaned xcodebuildmcp processes accumulate and grind the system to a halt.

$ ps aux | grep xcodebuild
dale  24113 352.3 23.5 450778096 3945760  ??  R  3:59PM  1:15.03 node ...xcodebuildmcp mcp
dale  24114   0.0  0.3 446631664  48928   ??  S  3:59PM  0:00.84 node ...xcodebuildmcp mcp
dale  24053   0.0  0.3 435888672  47712   ??  S  3:59PM  0:00.63 npm exec xcodebuildmcp@latest mcp
dale  24052   0.0  0.3 435888944  47712   ??  S  3:59PM  0:00.64 npm exec xcodebuildmcp@latest mcp

Root Cause

start-mcp-server.js relies on stdin end/close events to detect parent death (lines 99–104). However, when spawned through npm exec, there's an intermediate node wrapper process. When the parent (Claude CLI) dies:

1. The npm exec wrapper becomes orphaned (reparented to launchd/PID 1)
2. The wrapper doesn't close its stdin pipe to the actual xcodebuildmcp process
3. The MCP server never receives the stdin end/close event
4. The process runs forever with no work to do

Additionally, unlike daemon mode (which has idle-shutdown.js with a 10-minute timeout), the MCP server mode has no idle timeout at all.

Suggested Fix

Add a parent-PID watchdog to start-mcp-server.js. When the parent process dies, macOS/Linux reparents the child to init/launchd (PID 1). Polling process.ppid detects this:

--- a/src/server/start-mcp-server.ts
+++ b/src/server/start-mcp-server.ts
@@ in startMcpServer(), after enrichSentryContext() and before shuttingDown declaration
+    // Parent-process watchdog: detect orphaned process when parent dies.
+    // When the parent (Claude CLI / npm exec) exits, the OS reparents us to
+    // init/launchd (PID 1). Poll every 5s and shut down if that happens.
+    const originalPpid = process.ppid;
+    const ppidWatchdog = setInterval(() => {
+      if (process.ppid !== originalPpid) {
+        clearInterval(ppidWatchdog);
+        log("info", `Parent process died (was ${originalPpid}, now ${process.ppid}); shutting down`);
+        void shutdown("parent-died");
+      }
+    }, 5000);
+    ppidWatchdog.unref(); // Don't keep the event loop alive just for this

This is 8 lines, zero dependencies, works on macOS and Linux, and has no effect during normal operation.

Environment

• macOS 15 (Darwin 25.3.0), Apple Silicon
• XcodeBuildMCP 2.2.1
• Claude Code 2.1.75 (VS Code extension)
• Launched via: npm exec xcodebuildmcp@latest mcp

🤖 Generated with Claude Code

[rebornix]

The memory leaks seem new and maybe it's highly relevant to how MCP clients handles the lifecycle of MCP servers. I once opened a repo with xcodebuildmcp setup in Codex App and only later on realized that I got nearly a dozen xcodebuildmcp servers running and quite a few of them taking more than 4G memory.

@cameroncooke any suggestion on how we can troubleshoot?

[cameroncooke]

I'll look into this. I would expect the client to manage sub process life cycle so unless XcodeBuildMCP is ignoring shutdown signals I would expect this to be a client issue. But given it's been mentioned to affect both Codex and Claude Code does indicate there maybe an issue on my end.

[rebornix]

It seems easier to trigger with Claude Code or Codex desktop apps too (VS Code has lazy startup so seems less severe). I'll give the fix a try. Thanks for the fast response!

[cameroncooke]

Could you both share what workflows you're running. Also if you can share the doctor tool output. You'll need to enable debug mode. Lastly can you confirm if you're using MCP or CLI?

[cameroncooke]

@dalegass @rebornix can you share the MCP doctor output, you'll need to configure XcodeBuildMCP with the XCODEBUILDMCP_DEBUG=1 envar, or debug: true in the .xcodebuildmcp/config.yaml file, then your agent to run the doctor tool and return the tool output verbatim. Don't use the doctor tool via the CLI interface as the CLI has a different environmental setup.