Paws
Guide · macOS · Claude Code

Claude Code leaves orphaned MCP processes on your Mac. Here’s how to find them safely.

If you run Claude Code with a few MCP servers, your Mac can slowly fill up with processes that outlived the session that started them. Each one is small. Together they can hold tens of gigabytes — and neither Activity Monitor nor the “out of application memory” dialog will point at them.

This is a known problem. The open issue anthropics/claude-code#1935 (“MCP servers not properly terminated when Claude Code exits”) has dozens of comments, and similar reports keep arriving — e.g. #33947 and #95821 on macOS.

What it looks like

On the Mac where this guide started (M4 Max, 64 GB, 55 days of uptime) the cause was 2,750 orphaned chroma-mcp processes holding 34 GB. The dialog blamed Safari (1.15 GB) and Terminal (1.69 GB). Both were innocent.

Why it happens

A stdio MCP server is a child process of the Claude Code session that launched it. When the session ends uncleanly, or a server is restarted and the old child isn’t reaped, the child keeps running. macOS re-parents it to launchd (PID 1), and nothing ever asks it to exit. Subagents and dev servers they spawn can end up the same way.

Count them yourself (read-only)

This only reads the process list. It lists commands that have three or more identical copies with no living parent, skipping Apple’s own system processes:

ps -axo ppid=,rss=,command= | awk '$1==1 && $3 !~ /^\/(System|usr)\// && /(node|npx|uvx?|python[0-9.]*|bun|deno|mcp)( |$|\/)/ {rss=$2; $1=$2=""; sub(/^ +/,""); n[$0]++; m[$0]+=rss} END {for (c in n) if (n[c]>=3) printf "%5d  %8.1f MB  %s\n", n[c], m[c]/1024, substr(c,1,80)}' | sort -rn | head

Empty output is good news. If you see the same MCP server dozens or hundreds of times, you’ve found it.

Why “count everything with ppid=1” is the wrong test

The tempting one-liner is ps -eo ppid= | awk '$1==1' | wc -l. On a healthy Mac that returns hundreds — 883 on mine as I write this — and almost none of them should be touched. Spotify, browser helpers, and dozens of Apple XPC services all legitimately have launchd as their parent. Having no parent is an absence of information, not evidence.

I learned this the hard way: the first build of my own cleanup tool treated “not in launchctl list” as proof of being an orphan and terminated 108 Apple XPC services, including the ones Safari uses to render pages. That’s why the command above skips /System and /usr and only reports piles of three or more.

CPU is an even worse signal. A Claude Code session waiting for your input sits at 0% CPU. Anything that reaps “idle” processes will kill your work.

Cleaning up by hand

  1. Finish or quit every Claude Code session you care about first.
  2. Kill one group at a time, by the exact name you saw above, for example pkill -f chroma-mcp.
  3. Run the count again. Restart Claude Code; it starts fresh servers when it needs them.

Rebooting also clears everything — until it builds up again.

If you’d rather not do this every few days: I built Paws, a menu bar app that watches memory and finds these piles for you. Instead of CPU or ppid, it asks the kernel whether a terminal session still owns the process (e_tpgid), and protection spreads upward to parents — so a live agent is never on the list. Nothing is pre-checked, every termination is logged, and watching is free forever. Cleaning is $29 once, for three Macs.

FAQ

Is this only a macOS problem?

No — the GitHub issues include Linux and Windows reports. The command and the app on this page are macOS-only.

Will killing an orphaned MCP server break Claude Code?

Not if no session owns it any more; a running session starts its own servers. The risk is killing one that a live session still uses — which is why you quit sessions first, or use a tool that checks session ownership.

Does Activity Monitor show them?

Yes, as separate rows — each one small enough to sit far below the top of the list. You’d have to notice that the same name appears hundreds of times.