Guides/Claude Code using too much memory
Claude Code using too much memory or CPU on a Mac? How to find it, and get it back
Quick answer
Claude Code runs in your terminal as a process named claude, and starts others as it works: MCP servers, sub-agents, and the dev servers and test runs it uses to check its work. Two things make it heavy. A session that has run for hours can grow in memory and CPU; quitting and resuming it with claude --resume brings it back to normal. And processes it started can stay running after the session ends. Find them in Activity Monitor by searching for claude, node and mcp. Vitals, a system monitor for the Mac, lists every process working in each project folder, so what a session left behind is in plain view.
How to find what Claude Code is using
- 01 Open Activity Monitor, click Memory, and type claude in the search field. Each running session is a row. A row using several gigabytes, or busy while you are not asking it anything, is the one to restart.
- 02 Choose View → All Processes, Hierarchically. Open the triangle beside your terminal app to see each session with everything it started underneath.
- 03 Restart a heavy session: press Control-C twice to quit it, then run
claude --resumein the same folder and pick the conversation. It carries on where it stopped. - 04 Clear the search field and search for mcp, then for node. Rows that are still there after you have closed every Claude Code session were left behind.
- 05 In Terminal,
ps -axo pid,ppid,rss,etime,command | grep -i mcplists them with their parent. A parent of 1 means the session that started the process is gone. Stop one withkillfollowed by its number.
In Claude Code, /mcp lists the MCP servers a session starts. Each is a process of its own; remove the ones you do not use.
Claude Code is a command-line program, so it has no window of its own and no entry in the Dock: its cost shows up under your terminal app, or under the editor whose terminal you run it in. It is also a program that starts other programs. Every MCP server is a process, every sub-agent is a process, and when it runs your tests or starts your dev server, those are processes too. Most of the memory people blame on Claude Code is in what it started. The table sorts out which is which.
Where Claude Code’s memory and CPU go
| What you see | What it is | What to do |
|---|---|---|
claude using several GB | A session that has been open for hours | Quit it and run claude --resume |
claude busy while idle | The same: long sessions slow down | Restart the session; update Claude Code |
Many node processes | MCP servers, one per server per session | Remove unused servers with /mcp |
| Processes left after every session is closed | MCP servers, sub-agents or a headless browser that did not stop | Find them by parent 1, and quit them |
next-server, a test runner or a build at high CPU | Something Claude Code started to check its work | Stop it, or ask Claude Code to |
Long sessions grow
A session keeps its whole conversation, every file it read and every command’s output. Over hours that adds up, and people have reported sessions on Claude Code’s issue tracker that reached many gigabytes, or kept a CPU core busy while idle. The reports agree on the fix: quit the session and resume it. The conversation is saved as you go, so claude --resume loses nothing and starts from a clean process.
Keeping Claude Code up to date matters more than with most tools. It ships often, and memory problems are among the things fixed between versions. claude update updates it.
What a session leaves behind
When a session ends, the processes it started are meant to end with it. They do not always. An MCP server, a sub-agent or a headless browser can lose its parent and carry on, holding its memory with nothing using it. One developer who wrote about it counted 37 such processes holding more than 6 GB after a day’s work.
These are easy to recognise once you look: no terminal, a parent of 1, and a start time hours ago. They are safe to quit. A zombie process, strictly, is something else: it has already ended and uses no memory. What people call zombies here are orphans, alive and holding memory.
Dev servers, tests and builds
To check its work, Claude Code starts your dev server, runs your tests, or builds the project. A dev server it started in the background is still serving after the task is done, and after the session is closed if nothing stopped it. Two or three projects each with a forgotten dev server is a common reason a Mac with plenty of memory runs short.
Ask Claude Code to stop what it started before you end a session, or check which ports are being listened on: a server on a port you are not using is a server nobody is using.
Several sessions at once
Running agents in parallel, one per task or per branch, multiplies everything above: each session has its own memory, its own copy of every MCP server and its own dev server. On a 16 GB Mac that is the difference between comfortable and memory pressure in the yellow. Close sessions that have finished, and give servers different ports so a second one does not quietly fail and retry.
What Vitals adds
Vitals shows what each project is costing, including the processes no window owns.
- A Projects tab: every process working in a project folder, whichever terminal or editor started it, with memory, CPU and energy for the project as a whole
- The ports each project is listening on. Dev servers left running idle are pointed out, with an offer to stop them
- Claude Code counted as one tool even as it updates itself, so its memory over the day is one line
- A notification when an app’s memory keeps growing or it holds the CPU for minutes
- Quit for any app from the menu bar, after asking
Good to know
- Vitals shows processes and what they use. It does not read Claude Code’s conversations or know what a session is working on.
- Vitals never quits anything by itself.
Questions people ask
Why is Claude Code using so much memory?
A session that has been open for hours grows, and each MCP server, sub-agent and dev server it starts is a process of its own. Quit the session and run claude --resume to carry on from a clean process.
Does restarting Claude Code lose my conversation?
No. Conversations are saved as you go. Run claude --resume in the same folder and choose the conversation to carry on.
Why are there so many node processes when I use Claude Code?
Most are MCP servers: each server runs as its own process, once per session. In Claude Code, /mcp shows which are configured.
How do I find processes Claude Code left running?
Close every session, then search Activity Monitor for mcp and node. In Terminal, ps -axo pid,ppid,rss,command shows each process’s parent; a parent of 1 means it was left behind.
Is it safe to quit leftover MCP server processes?
Yes, once no Claude Code session is open. A session starts the servers it needs again the next time it runs.
How much memory does Claude Code need?
A fresh session uses a few hundred megabytes. The rest depends on what it starts: MCP servers, a dev server, a test run. Several sessions in parallel multiply all of it.
Is there an app that shows what Claude Code is running on my Mac?
Vitals has a Projects tab that lists every process working in each project folder, with its memory, CPU and ports, and points out dev servers left idle.
In the glossary
More guides
- Why is my Mac so slow
- What’s draining my Mac’s battery
- Which app is using my CPU or memory
- Why won’t my Mac sleep
- Chrome using too much memory
- Why are my Mac’s fans so loud
- How to control fan speed on a Mac
- How to free up RAM on a Mac
- Docker using too much memory
- How to stop Docker containers
- Volume mixer for Mac
- Cursor using high CPU
- Claude app using high CPU
- Codex using high CPU
- Ollama using too much memory
- Activity Monitor alternatives
- iStat Menus alternatives
- Stats alternatives
- Task Manager for Mac
- Best system monitors for Mac
- Best menu bar monitors for Mac
- Best volume mixers for Mac