Claude Code using too much memory on your Mac? Find where it goes

You open Activity Monitor because the fans are loud or the Mac feels sluggish, and find dozens of node, claude and python entries with no hint of which session started them. This guide shows how to work out where the memory actually goes, one Claude Code session at a time.

Where the memory goes

A single Claude Code session is rarely a single process. Its memory is spread across:

• The session itself, the claude process holding the conversation.
• Subagents, extra claude processes for parallel tasks.
• MCP servers. Every enabled server starts once per session. Five sessions with four servers each is twenty extra processes.
• Whatever the agent ran: dev servers, test runners, builds, a headless browser. These are often the largest part.
• Leftovers from sessions you already closed. See finding orphaned Claude Code processes.

Activity Monitor lists all of these as unrelated rows. To see the real cost of a session you need to add up its whole process tree.

Step 1: check whether memory is actually the problem

memory_pressure

The last line reports the system-wide free memory percentage. In Activity Monitor, the Memory tab's Memory Pressure graph tells the same story: green is fine even if "Memory Used" looks high, because macOS fills spare RAM with cache on purpose. Yellow or red, or a growing Swap Used figure, means you are short.

Step 2: find your sessions

pgrep -lf claude

This prints the process id and command of every process with claude in its command line. The session processes are the ones you started from a terminal; note their ids.

Step 3: add up memory per session

Paste these two shell functions into your terminal (or your ~/.zshrc):

# Print a process id and all of its descendants
tree_pids() { echo "$1"; for c in $(pgrep -P "$1"); do tree_pids "$c"; done; }

# Total resident memory of a process tree
tree_rss() {
  ps -o rss= -p "$(tree_pids "$1" | paste -sd, -)" |
    awk '{ kb += $1 } END { printf "%.0f MiB\n", kb / 1024 }'
}

Then run it for each session id:

tree_rss 48211

To see which members of a tree are the heavy ones, list them sorted by memory:

ps -o pid,rss,%cpu,command -p "$(tree_pids 48211 | paste -sd, -)" | sort -k2 -nr | head -15

Step 4: check the disk as well

Agents install dependencies and run builds, and those folders grow fast. When memory runs short, macOS swaps to the same disk, so a nearly full disk makes memory pressure worse. In the project folder:

du -sh node_modules target .venv .next dist 2>/dev/null

How to get the memory back

• Stop leftovers first. Processes from closed sessions are pure waste. Follow the orphaned processes guide.
• Stop whole trees, not single processes. Killing only the session process can leave its MCP servers and dev servers running. See how to kill a whole process tree on macOS.
• Restart long-running sessions. Several reports describe a session's memory growing the longer it runs (issue #21305). Starting fresh resets it.
• Trim MCP servers per project. claude mcp list shows what is enabled; remove what that project does not need.
• Run fewer sessions at once when the machine is close to its limit, or stop the dev servers an idle session left up.

How Agents Monitor shows this

Agents Monitor does this bookkeeping continuously. It groups every process under the agent that started it and shows live CPU, memory, disk writes and listening ports per process and per tree, refreshed every two seconds. Heavy folders in each agent's working directory, such as node_modules and target, are measured every minute with their growth rate.

You can set a memory limit per process or per tree. When a tree stays over it for 10 seconds, you get one macOS notification, not a flood, and the menu-bar icon shows the alert until it clears.