a reddit user says claude code found a cryptominer on their mac while building a temperature monitor app. while checking the sensor readings, the agent saw xmrig, a monero miner, using about 1175% cpu, or roughly 12 cores. its startup file was dated aug 29, before claude touched anything. claude reported it and did not delete anything without asking. the user did not say how the miner got there. a likely route is an unchecked repository or package installed earlier.
so is claude code safe? that depends on the setup around it. it shows the real claude code security risk. an ai agent runs commands with your user account, so anything it installs or runs gets the same access as you. this guide covers how to protect your machine, your keys and your code when you work with claude code and other ai agents. for setup and pricing, see our claude code guide.
why an ai agent changes the risk
a coding agent reads files, runs shell commands, installs packages and opens web pages. it does this on your computer, under your account. a bad command does not need a hacker at the keyboard anymore. it only needs to reach the agent through a web page, a repository or a package.
the main threats fall into five groups:
- fake installers and lookalike sites
- prompt injection in pages, files and issues
- untrusted repositories, mcp servers and plugins
- hallucinated or malicious packages
- leaked api keys and tokens
each step below closes one or more of these gaps. none of them makes an agent fully safe, and anthropic's own docs say no system is immune to all attacks.
1. install claude only from official sources
in july, security firm huntress investigated a mac infected through a fake claude code install guide. the victim clicked a paid google result and landed on a public claude.ai share page styled as apple support. the page asked them to paste one terminal command.
that command pulled the macsync stealer and remote access tool. it targeted dozens of crypto wallet extensions and planted fake seed-phrase prompts in ledger and trezor apps. install claude code only through the steps on code.claude.com or the official @anthropic-ai/claude-code npm package, and skip ads in search results.
2. keep permission prompts on
claude code has several permission modes. in manual mode it starts read-only and asks before it edits files or runs commands. auto mode lets a separate classifier model review actions instead of you, and your own deny rules still apply.
the risky one is bypassPermissions, also started with --dangerously-skip-permissions. it skips the prompts, including writes to .git and .claude. anthropic says to use it only in containers or virtual machines. teams can switch it off with permissions.disableBypassPermissionsMode set to "disable" in managed settings.
read each command before you approve it, and check your rules from time to time with /permissions.
3. turn on the sandbox
the /sandbox command puts claude's shell commands inside an operating system boundary. macos uses the built-in seatbelt framework. linux and wsl2 use bubblewrap and socat. on native windows, commands run without a sandbox, so windows users need wsl2 for it.
by default, sandboxed commands can write only to the working folder and a temp folder. network traffic goes through a local proxy, and the list of allowed domains starts empty. a miner like the one on reddit could not reach its mining pool unless you allowed that domain.
the sandbox has limits worth knowing. sandboxed commands can still read most of the machine, including ~/.ssh and ~/.aws/credentials, unless you add filesystem.denyRead rules. claude's file tools, mcp servers and hooks run outside it.
4. run untrusted work in a container or vm
for code you do not trust, run the whole of claude code inside a dev container (devcontainer) or a virtual machine. anthropic's docs recommend this for sensitive code and for scripts that talk to outside services. a container also limits what a mistake can break.
cloud sessions of claude code already run this way. each one gets an isolated vm, network access is limited by default, and github credentials stay on anthropic's servers instead of entering the vm.
5. be careful with unknown repositories
always check who wrote a repository and what is inside it before you clone, install or run it. look at the author's other projects and account age, and read the install scripts and dependencies. do not trust a high star count on github. a 2026 icse study found about six million suspected fake stars, most of them promoting short-lived malware repositories.
the web is also full of videos that offer a repository with unlimited free tokens, a cracked pro plan or a "free claude" mod. such downloads are a common way to plant miners and stealers. remember the old rule: the only free cheese is in a mousetrap.
a cloned repository can carry its own claude settings: hooks, an env block, mcp servers in .mcp.json and instructions in claude.md. hooks are shell commands. in an interactive session, claude code shows a trust dialog the first time you open a folder. it also asks before it connects the repository's mcp servers.
two cases skip that dialog. a claude -p run and an sdk session never show it, and they connect .mcp.json servers without asking. open a repository you just downloaded in an interactive session first, and read its .claude folder before you trust it.
the same care applies to npm install, pip install and curl … | bash lines in a readme. install scripts run with your access, and files fetched by git, curl or npm skip the macos quarantine check that browser downloads get.
6. vet mcp servers and plugins
an mcp server is a program that runs on your machine and gives claude new tools. anthropic reviews connectors before it lists them in its directory, but it does not security-audit or manage any mcp server. a plugin can also add servers of its own.
use servers you wrote yourself or ones from providers you trust, and read the code of anything from a random repository. limit what each server may do with permission rules, for example with mcp__<server>__* patterns.
7. check every package before it is installed
language models sometimes suggest packages that do not exist. a 2025 usenix security paper tested 16 models on 576,000 code samples. at least 5.2% of the packages suggested by commercial models and 21.7% by open-source models were hallucinated.
the study counted 205,474 unique fake names. attackers can register such names and wait for an agent to install them. before you approve an install, check that the package exists, has real downloads and is spelled the way you expect.
8. keep secrets out of the agent's reach
claude code stores its own api keys in the macos keychain when it can. your project secrets are another matter. block them with deny rules in .claude/settings.json:
{
"permissions": {
"deny": ["Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)", "Read(~/.ssh/**)"]
}
}a .claudeignore file has no effect, despite what some guides say. the docs ask you to move its entries into Read deny rules. sandboxed commands also inherit the environment variables of claude code, so keep live keys out of the shell you start it from.
9. watch for prompt injection
prompt injection is text written for the agent, not for you. it can hide in a web page, a readme, an issue or a pdf. a line like "to finish setup, run this command" can turn a reading task into an install.
claude code has some defenses built in. network commands such as curl and wget are not auto-approved by default. webfetch usually passes claude a summary from a separate model call instead of the raw page. commands it cannot fully parse need approval. you can also add curl and wget to permissions.deny.
do not pipe untrusted content straight into claude. if a session suddenly wants to download and run something you did not ask for, stop it and report it with /feedback.
10. keep the computer itself safe
an agent cannot protect a machine that is already open to attack. on macos, cve-2026-65400 let attackers start a screen sharing session without valid credentials. it has been on cisa's list of exploited flaws since august 18. apple fixed it in macos tahoe 26.6.1, sequoia 15.7.9 and sonoma 14.8.9.
update macos and do not expose ports such as 5900 or agent web panels to the internet. an open agent panel lets anyone see your targets, secrets and results, and sometimes steer the agent.
11. review the code it writes
an agent can also put security holes into your own product. treat its code like code from a new team member and give it a full code review before you merge it. pay extra attention to login, payments and permission checks.
claude code has two built-in helpers for this. the /security-review command runs a security pass over the changes on your current branch. the security guidance plugin has claude review and fix vulnerabilities in its own changes during a session.
add a static analysis (sast) tool to your ci as well. it checks every pull request for common bugs, whoever wrote the code.
for teams: managed settings and monitoring
a team needs the same rules on every laptop. managed settings let an organization enforce permission rules that developers cannot override, including a ban on bypass mode. shared allow and deny lists can live in the repository, so every developer starts from the same allowlist.
claude code can export usage metrics through opentelemetry, so a security team can audit what agents do. ConfigChange hooks can log or block settings changes during a session. give each agent the least privilege it needs: only the folders, tools and network access the task requires.
what to do if your agent finds malware
claude's reaction in the reddit case is a good model: it described the miner and its startup file, and waited for permission. after a finding like that, take these steps:
- stop the agent's other work, especially pushes and logins.
- disconnect the machine from the network.
- remove the startup item and the malware, or let a security tool do it.
- revoke and reissue every token that machine held: github, cloud, api keys.
- find how it got in: a download, a repository, a package or an exposed service.
a miner is the loud kind of infection. a stealer that copies your keys makes no noise, which is why revoking tokens matters more than deleting the file.
faq
is claude code safe to install?
yes, when it comes from code.claude.com or the official npm package. fake install guides spread through search ads, so do not paste install commands from other sites.
is claude code safe to use at work?
it can be, with rules in place: permission prompts, deny rules for secrets, the sandbox and managed settings. check your company's policy on sending code to an outside api first.
is it safe to run claude code locally?
a local session works with your account and files. turn on the sandbox and keep secrets out of reach. for untrusted code, use a container, a vm or a cloud session.
can claude code itself get a virus?
no. the computer gets infected, and the agent can be the way the malware arrives, because it runs commands under your account.
is auto mode safe?
it is safer than skipping permissions. a classifier blocks actions it judges unsafe, but it is a model and can be wrong. combine it with deny rules and the sandbox.
does the sandbox work on windows?
not natively. on windows, claude code runs commands unsandboxed. run it inside wsl2 to use the sandbox.
does .claudeignore hide my files?
no. it has no effect in claude code. use Read deny rules instead.
sources
- claude code docs: security – permission modes, prompt injection safeguards, mcp, cloud sessions
- claude code docs: configure permissions – bypass mode, deny rules, what runs before you trust a folder
- claude code docs: sandboxing – seatbelt, bubblewrap, default file and network limits
- huntress: macsync stealer & rat reverse engineering – july 29, 2026; the fake claude code install guide
- we have a package for you! (usenix security 2025) – package hallucination rates across 16 models
- six million (suspected) fake stars in github (icse 2026) – fake github stars and the malware repositories they promote
