Environment: Proxyman 6.14.0, macOS Tahoe 26.5 (Darwin 25.5.0), Apple Silicon (M4 Pro)
Summary
/Applications/Proxyman.app/Contents/MacOS/mcp-server does not exit when its stdin reaches EOF. Per the MCP spec, a stdio transport server should shut down when the client closes the input pipe. Because Proxyman's server ignores this, every MCP client session that ends leaves an orphaned mcp-server process behind (reparented to launchd, PPID 1), and it lingers indefinitely.
Repro (isolated, no MCP client needed)
/Applications/Proxyman.app/Contents/MacOS/mcp-server </dev/null
stdin is at EOF immediately — the process should exit right away. Instead it stays alive indefinitely.
Real-world impact
I use Claude Code with the Proxyman MCP server configured. Each CC session spawns one mcp-server instance; none of them ever exit. After a few days of heavy use I found 1,088 orphaned mcp-server processes consuming a combined ~7.8 GB of RAM:
ps -axo pid,ppid,etime,rss,command | grep "Proxyman.app/Contents/MacOS/mcp-server"
# 1,088 rows, all PPID 1, oldest > 5 days
All other stdio MCP servers on the same machine (firecrawl, exa, chrome-devtools, 1Password) exit correctly under identical conditions — Proxyman's is the only one that orphans.
Expected
Monitor stdin; on EOF (client closed the pipe / parent exited), exit promptly.
Suggested fix
Add a read-loop termination or a dedicated stdin watcher: when read() on stdin returns 0 (EOF), call exit(0). Optionally also watch for parent-process death as a belt-and-braces measure.
Thanks — happy to provide any further diagnostics.
Environment: Proxyman 6.14.0, macOS Tahoe 26.5 (Darwin 25.5.0), Apple Silicon (M4 Pro)
Summary
/Applications/Proxyman.app/Contents/MacOS/mcp-serverdoes not exit when its stdin reaches EOF. Per the MCP spec, a stdio transport server should shut down when the client closes the input pipe. Because Proxyman's server ignores this, every MCP client session that ends leaves an orphanedmcp-serverprocess behind (reparented to launchd, PPID 1), and it lingers indefinitely.Repro (isolated, no MCP client needed)
stdin is at EOF immediately — the process should exit right away. Instead it stays alive indefinitely.
Real-world impact
I use Claude Code with the Proxyman MCP server configured. Each CC session spawns one
mcp-serverinstance; none of them ever exit. After a few days of heavy use I found 1,088 orphanedmcp-serverprocesses consuming a combined ~7.8 GB of RAM:All other stdio MCP servers on the same machine (firecrawl, exa, chrome-devtools, 1Password) exit correctly under identical conditions — Proxyman's is the only one that orphans.
Expected
Monitor stdin; on EOF (client closed the pipe / parent exited), exit promptly.
Suggested fix
Add a read-loop termination or a dedicated stdin watcher: when
read()on stdin returns 0 (EOF), callexit(0). Optionally also watch for parent-process death as a belt-and-braces measure.Thanks — happy to provide any further diagnostics.