If you use Claude Code, Codex or Cursor with MCP servers, each session starts its own copy of every server in its config. Four open sessions mean four copies, and a second app or profile multiplies them again.
In October my 16 GB Mac was swapping more than 7 GB. I keep several agent sessions open across apps, and most apps have more than one profile. Every session had started its own Playwright, GitHub and search servers, and some npx launchers were still running hours after their session had closed.
So I wrote a small tool that makes them share, and it has run on my machine since September. This week I rebuilt it for other people and released it as mcp-stdio-mux, MIT licensed.
Setup in one command
uvx mcp-stdio-mux setup
It finds Claude Code, Claude Desktop, Codex, Gemini CLI, Cursor, Windsurf and OpenCode, every profile included, shows which servers it will change and asks once. Each local server's command becomes mcp-stdio-mux run ... -- <your original command>, so the original stays readable in your config. Setup backs up every file first, and mcp-stdio-mux undo puts back the exact bytes.
It also installs a small skill for Claude Code and Codex, so you can ask the agent to share a server you add later.
What it handles
Any server an app starts as a local command. On my machine a dry run found 49 server entries in 15 config files across six apps, 17 different servers once the duplicates are folded together. Most are npx packages: GitHub, Postman, Cloudflare, Google Drive, Google search and Playwright. Then come uvx mcp-server-fetch, an mcp-remote bridge to a hosted server, a project started with uv run, and plain binaries such as serena and tilth.
Three kinds get special treatment. Playwright's tools drive a browser, so every session keeps its own Playwright. A server started from a relative path, such as uv run or node dist/index.js, gets one process per project folder. A server that already runs its own daemon, such as codebase-memory-mcp, is left as it is.
What it saves
Four sessions of one server on a 16 GB Apple silicon Mac, counting every process the sessions caused, measured on 10 November 2026:
| Server | Without | With mcp-stdio-mux |
|---|---|---|
| serena (Python) | 679 to 757 MB | 202 MB |
| context7 (npx) | 426 to 452 MB | 128 to 160 MB |
| GitHub MCP (npx) | 272 to 293 MB | 90 to 113 MB |
| tilth (Node) | 57 MB | 36 MB |
The unit is phys_footprint, the Memory column in Activity Monitor, over three runs per server. Each npx server is two processes per session, npm exec and node, so four sessions start eight of them; with the mux, one pair serves all four. The script behind these numbers is in the repository if you want to run it against your own servers.
Which sessions share a process
Two sessions use one backend only when the profile, the exact command, the credentials in the config and, for servers tied to a folder, the project all match. The mux compares credentials as a hash and never logs them. A work profile in Claude Code and a work profile in Codex share; your default profile and a client's profile do not, unless you say so.
Some servers keep state per client, such as an open browser tab or a login. The mux reads the tool names a server announces and gives those servers one process per session. It leaves remote (HTTP) servers and project .mcp.json files alone.
How a session costs 1.2 MB
My first version kept a small Python process in each session to relay messages to the shared one. It used 18 MB per session, and with a light server the relays cost more than the servers they replaced.
Now that process lives only for a moment. It finds or starts the shared daemon, hands over its stdin and stdout through a Unix socket (SCM_RIGHTS), and replaces itself with /bin/cat named after the server. The app still has a child process it can watch and stop, at about 1.2 MB, while the daemon reads the session's pipes directly.
What a second reviewer found
I built this the way I build client work: AI coding agents under my rules and tests. Before the release I gave the code to a separate agent that could not see my reasoning and asked it to break it.
It found 15 problems and reproduced every serious one. In the worst, a session that closed in the middle of a tool call had its late reply sent to every other session. One reply over 16 MB froze all of them, and a session that stopped reading held up the rest. That first bug had been in my own setup since September.
Every serious one is fixed in the release, each with a test that failed first. The suite has 91 tests and runs on macOS and Linux.
Try it
uvx mcp-stdio-mux setup --dry-run # the plan, nothing changed
uvx mcp-stdio-mux setup # apply after one question
mcp-stdio-mux status # what is shared and what it costs
The code and the known limits are on GitHub. If your team runs a lot of agents and you want this kind of tooling around them, let's talk.
Top comments (0)