How Do I Fix Mac Memory Pressure from Codex and Claude Code Agents?

How do you fix Mac memory pressure caused by AI agents?

Audit first, then clean up only what you can identify. Watch the memory pressure graph in Activity Monitor while agents work, check storage in System Settings, and list the dev servers, browsers, logs and Git data that agents left behind. Close what is finished, give each agent a clear stopping point, and run only one or two heavy jobs at a time. Buying more RAM raises your ceiling, but it does not stop the load from growing.

Why do agents slow your Mac if the model runs in the cloud?

Ask Codex or Claude Code to build a small website and the model may well answer from a remote server. Everything around it still runs on your Mac: the development server, the browser that checks the page, the build tools, the dependency installs. Start a second agent on a different project and it brings its own set of tools.

Then the work ends and your attention moves on, but those processes do not. A dev server keeps listening. A browser keeps its tabs. Dependencies and build output keep taking disk space. Each one holds a claim on memory or storage even though nobody is using it.

The load also stacks across tools. A browser with an agent extension, another browser for your own work, Codex, Claude Code, a transcription app and a local model server all draw from the same pool. Vendors do ship fixes (OpenAI recently shipped a Codex change that reduces its memory use), but these point fixes from the labs are not enough, especially if, like most people, you run multiple harnesses.

How do you read memory pressure and storage on a Mac?

Start with two built-in views.

1. Open Activity Monitor and click the Memory tab. Run your normal agent work and watch the Memory Pressure graph. Green means the system is coping. Yellow and red mean it is struggling.
2. Sort the process list by memory. Note which apps and helper processes sit at the top, and which agent or tool each one belongs to.
3. Open System Settings, General, Storage and see what is consuming disk space. macOS can use storage as swap, so a full disk and a memory-starved machine make each other worse.

A high number in the RAM used bar does not by itself mean you need a new computer. It means you should look at what is using it. If you run a mixed setup, try to separate the cases: what a local model like Qwen takes when it is loaded, versus what Codex or Claude Code and their browsers take.

How do you find leftover dev servers and stray processes?

Before closing anything, work out what it is serving. A server for a finished project or an abandoned experiment is safe to close. One feeding a project you are still using is not.

These standard terminal commands help:

# Processes listening on network ports (dev servers show up here)
lsof -iTCP -sTCP:LISTEN -n -P

# Top memory users, sorted by memory
ps -axo pid,rss,command -m | head -20

Match each port or process to a project directory. Close the ones you no longer need, then check Activity Monitor again. If memory pressure and storage both ease, you found a real source. If nothing changes, the problem is elsewhere.

You can also hand this job to an agent, as long as you set the ground rules. A safe diagnostic request reads roughly: inspect my computer, change nothing, identify the largest memory users and the relevant directories, explain what each belongs to, and propose specific fixes. Review the report, then approve cleanup item by item.

Can logs, crash reports and Git objects fill your disk?

Yes, and agentic software has had real cases of it. These come from public user reports on Codex, so treat them as examples of what to check, not as a description of your machine:

For the logging problem, Codex shipped logging fixes in June, and a later release added reclamation of unused log database space. That is progress, but it is also a reminder that these tools change fast and can wear on physical parts like an SSD.

To check your own machine, look at directory sizes and Git object counts in the projects your agents touch:

# Size of a suspicious folder
du -sh ~/path/to/folder

# Git object size in a repo
git count-objects -vH

Before deleting, ask whether the data can be regenerated. Build caches, installed dependencies and temporary output usually can. Your source files and anything unpushed cannot. Establish that first, then pick the cleanup method.

Worktrees add another source of growth. Separate working directories are useful for parallel agent work, but each can carry its own dependencies and build caches. Decide where and how you want to build before you multiply them.

How do you give agents stop conditions?

Agents are trained to keep going. Left alone, they leave things half-finished: a tab open on the working project, a chat with a server still running. Give each task a stopping point and a destination.

• Define what "done" means for the job.
• Tell the agent to save results in a predictable folder you both understand.
• Ask it to list which processes should stay running afterward, and close the rest.
• Have it inspect an existing project before scaffolding a new environment.
• Reuse a browser where that is appropriate instead of opening another.
• Record what you learn in project guidance so the next session starts with the same rules.

Local versus cloud environments does not remove this need. Local setups make it easy to switch between tools by pointing each at a directory, but either way something has to decide when the work ends.

How many agent jobs should you run at once?

Fewer than you think, and it depends on the work. If you queue twelve documents, you do not need twelve simultaneous browsers, converters and model requests. Run one or two heavy steps at a time and let the agent plan the rest.

A practical ramp:

1. Start with one active job and note memory pressure and finish time.
2. Add a second job and check both again.
3. If everything slows down, you hit the limit of the machine. Back off one step.

Core count does not translate directly into agent count. Two agents mostly waiting on cloud responses do little locally. Two agents running big builds or rendering video will use every CPU you have. One useful pattern is to let several agents research and plan in parallel while the heavy local build runs alone in a queue.

Do local model settings change memory use?

They do. If you run local models, the server settings matter as much as the model.

• Context size. A larger context uses more memory on a local model.
• Parallel requests. Multiple simultaneous requests add up.
• Keep-alive time. Keeping a model loaded reduces latency on the next request but holds memory between jobs.
• Docker Desktop limits. Docker Desktop lets you cap its virtual machine's resources and has an idle resource saver.

Model servers have controls for how you handle context and parallel requests and how long models remain loaded. Pick the trade-off based on how often you call the model.

Should you buy a bigger Mac?

Only after the audit. If you have closed leftovers, queued heavy work and profiled your load, and the machine is still maxed out, a hardware upgrade becomes a reasonable ROI question. Buying first just gives the same habits more room to grow, and agents will keep getting more capable and more demanding.

If you do upgrade, consider keeping the old machine running as a dedicated agent box. It may be slower, but it can take jobs off your main computer.