Claude Code Found an XMRig Miner on a Mac: How to Check Yours

This is a single user's account, repeated by several outlets. Nobody has independently verified how the miner got onto the Mac or that the cleanup was complete. I could not open the Reddit thread's comments from my tooling, so the community section below is limited to what the search listings and press coverage show.

A Mac user says Claude Code found a hidden XMRig cryptominer while helping them build a temperature-monitoring app. If you searched "claude code xmrig mac" because your own laptop is running hot, here is the short answer: sort your processes by CPU, then read your LaunchAgents folders. The commands are below. The story is also a useful test of what you actually want a coding agent to do on your machine.

What was reported#

The account comes from Reddit user u/UntilHEX. GBHackers summarises it: Claude Code was inspecting raw temperature sensor readings to check that the app worked, saw readings that looked too high, then looked at running processes and found XMRig. Tom's Hardware put the numbers in its headline: about 1,175% CPU, roughly 12 cores, and temperatures around 112 degrees.

The persistence details matter more than the headline numbers. According to GBHackers' reading of the thread, the miner ran from a temporary directory, connected to a mining pool at pool.hashvault.sh, and was kept alive by a macOS LaunchAgent that used an encoded script. The LaunchAgent had a KeepAlive setting, which means killing the visible process alone would not have ended it.

Yahoo Tech adds the cleanup: the agent proposed stopping the startup item, terminating the process and moving the files to quarantine, and asked for approval before acting. One file needed manual deletion, and a Malwarebytes scan was run afterwards. Both outlets say the infection route is unknown. Secondary coverage mentions the user suspecting cracked audio plugins, which GBHackers explicitly declines to treat as confirmed.

Why 1,175% is not a typo#

macOS shows a process's CPU as a sum across cores, so a process using 12 cores flat out reads near 1,200%. That is the same arithmetic as any multithreaded miner. XMRig's own documentation describes it as a unified CPU/GPU miner, which is why it saturates every core it is allowed to use. XMRig is legitimate open-source software; the offence is installing it on someone else's machine.

The angle: what a builder does Monday#

The interesting part is not that an AI "detected malware". The user had an unrelated task that made the agent read the machine's sensors, and the agent followed an anomaly to its cause instead of declaring the app done. Any coding agent with shell access can do that, and so can you in two minutes. Everything below is read-only until the last step.

1. Find what is burning CPU. Activity Monitor sorted by CPU works. In a terminal, top can sort by CPU and print a fixed number of samples (SS64 reference for the flags):

top -o cpu -l 2 -n 10

The command prints two samples; compare the second. A process you did not start, running from a temporary or hidden directory and pinned near a multiple of 100%, is the pattern in this report.

2. List where background jobs are registered. Apple's launchd documentation says agents live in /Library/LaunchAgents or in the LaunchAgents folder of a user's Library, and daemons in /Library/LaunchDaemons (Apple, Creating Launch Daemons and Agents):

ls -la ~/Library/LaunchAgents /Library/LaunchAgents /Library/LaunchDaemons
launchctl list

Look for labels and files you cannot match to software you installed, especially recent ones.

3. Read a suspicious plist before touching it. plutil -p prints a property list in readable form (SS64):

plutil -p ~/Library/LaunchAgents/<suspicious-file>.plist

Check ProgramArguments for a path under a temp directory or an encoded blob, and KeepAlive, which Apple's guide describes as the key that makes a job run at all times.

4. Remove the job, then the files. launchctl bootout removes a service from its domain, and the gui/<uid> form targets your login session (SS64 launchctl reference):

launchctl bootout gui/$(id -u) ~/Library/LaunchAgents/<suspicious-file>.plist

Then move the plist and the binary somewhere you can inspect them rather than deleting outright, and run a reputable scanner. A clean scan is not proof of a clean machine, and if you find a real miner, assume whatever installed it could have done more: rotate the credentials that were on that Mac.

Where an agent helps and where it should not#

Notice what the reported cleanup looked like: the agent proposed steps and waited for approval. That is the posture to keep. An agent that can run launchctl and delete files is also an agent whose mistakes, or whose prompt-injected instructions, run with your privileges. Our Claude Code permissions guide covers allow, deny and ask rules, and auto mode is the setting to think hardest about before pointing an agent at a machine you suspect is compromised. If an agent investigates, let it read; keep the removals as explicit approvals you read first.

There is also a sharper version of the lesson. If the Mac really was compromised, everything on it was exposed, including the tokens your agents use. The same logic is behind our posts on agent config files as executable supply chain and keeping API keys away from coding agents.

What people are actually saying#

• Excitement, mostly. The story spread across several subreddits, including r/claude, r/ClaudeCode and r/ClaudeMCP, under headlines like Claude caught a cryptominer on my Mac whilst building me a temperature monitor and Building a temperature monitor turned into a malware investigation. Press coverage ran with the "AI found malware" framing.
• The caution. Both GBHackers and Yahoo Tech stress that this is one unverified report, that it does not show Claude Code is a malware scanner, and that it cannot replace endpoint security. I agree: the miner was already making the machine slow and hot, so Activity Monitor would have shown it to anyone who looked.
• A related experience. A separate r/cybersecurity_help thread describes a different person's Mac running XMRig at around 800% CPU, with a data logger found afterwards. I only saw its search excerpt, so treat it as a reminder that miners often are not the only thing on an infected machine.

The fair counter-case: nothing here shows the agent was faster or better than a human or a scanner. What it shows is that an agent already looking at the system will follow evidence you did not ask about, which is useful only if you also control what it is allowed to do next.

Continue Reading#

• Claude Code Permissions: settings.json Allow, Deny, Ask - the rules that decide what an agent may run on your machine
• Claude Code Auto Mode Explained - permissions without prompts and when that is safe
• Agent Config Files Are Executable Supply Chain - why files an agent reads can run code
• LiteLLM 1.107.0 Compromised: Check, Clean and Rotate - another check-clean-rotate runbook from this week

Sources#

• Tom's Hardware - Claude Code AI agent caught a crypto miner hiding on a developer's overheating Mac (headline and metadata only; the article body did not load)
• GBHackers - Claude Code Detects Hidden XMRig Cryptominer Consuming 1175% CPU on Mac
• Yahoo Tech - Claude Code Spotted a Cryptominer On Mac
• Original Reddit thread, r/claude (listing only; not opened)
• XMRig documentation
• Apple - Creating Launch Daemons and Agents
• SS64 - top, plutil, launchctl