Your Mac Blocked a Terminal Paste: What the Alert Means

You were told to paste a command into Terminal. Maybe a support page said it would fix your problem. Maybe a verification screen said it would prove you were human. Maybe a download page said it was the fastest way to install something. You copied it, opened Terminal, pressed Command-V, and your Mac stopped you with a security alert.

The first reaction almost everyone has is that macOS is being paranoid. Sometimes that reaction is correct. Legitimate software really does ship install instructions that ask you to paste a command, and a protection tuned to catch attackers is going to catch some of those too. But sometimes the alert is the last thing standing between a stranger and your Apple Keychain, your browser passwords, and any cryptocurrency you keep on that machine.

This article tells you which situation you are in. It covers all three of the protections Apple added, what each alert actually means, whether you can override it and what overriding really costs, why you got the prompt when your developer friend never has, what happens on third-party terminals like iTerm2 and Ghostty, and a decision rule you can apply in about thirty seconds without needing to understand shell syntax. If you already pasted and ran something, there is a calm, ordered runbook further down. Start there and come back for the explanation later.

Key Takeaways

• There are three separate protections, not one. Apple's Platform Security documentation describes Terminal Paste Protection, Pasteboard Command Blocking, and AppleScript scanning as distinct mechanisms introduced in macOS 26.4 or later. Knowing which one fired tells you how seriously to take it.
• Overridable and non-overridable alerts mean very different things. A heuristic match offers you a way through. A known-malware signature match does not, and neither do scripts executed from memory. If your Mac gives you no button to proceed, that is not a bug to work around.
• Third-party terminals lose the prompt but keep the backstop. Apple documents the paste warning as a Terminal app feature, while pasteboard command blocking explicitly covers any terminal emulator, including third-party applications, because it works at the XProtect level on the resulting process tree.
• The attack these protections exist to stop shows different pages to different visitors. Microsoft Threat Intelligence research reported on 2026-08-05 described a macOS ClickFix operation whose pages fingerprint each visitor and hunt for researchers, which means checking a link yourself proves nothing about what someone else was shown.
• The stakes are your whole credential set, not one password. Huntress researchers described a Go-based macOS stealer that targets browser password databases, cookies, and the Apple Keychain, with a crypto-draining function tunable down to 1% of a balance so the theft stays quiet. One monitored Mac had been compromised roughly three months before anyone noticed.

The Three Protections, and Which One You Just Hit

Apple's Platform Security documentation page on Terminal and script protections describes three mechanisms introduced in macOS 26.4 or later. They are frequently discussed as if they were a single feature, which causes a lot of confusion, because they behave differently, they cover different software, and only some of them can be overridden.

Read this section first. Once you know which of the three you hit, everything else in this article gets easier to apply.

Protection 1: Terminal Paste Protection

This is the one most people mean when they say their Mac blocked a paste. It is a warning dialog shown by Apple's Terminal app when you paste text into it from a category of source applications that attackers commonly use to deliver a command: web browsers, Messages, Mail, Preview, and messaging apps.

The key word is warning. This protection is about interrupting a moment of social engineering. It puts a speed bump between the instruction you were given and the action you were about to take, at exactly the point where the attack depends on you not stopping to think.

Apple documents specific conditions that must all hold before this protection triggers. It is deliberately narrow, which is why most people have never seen it. We will go through those conditions in detail shortly, because understanding them answers the most common question about this feature, which is why it appears for some people and never for others.

Protection 2: Pasteboard Command Blocking

This one operates at a completely different layer, and it is the protection most coverage underplays.

Apple's documentation states that when a user pastes text into any terminal emulator, including third-party terminal applications, XProtect traces the resulting process tree and inspects its behavior. Two things then happen. Network artifacts are checked against Apple's Safe Browsing Service, and processes that match known malicious sources are blocked. Separately, behavioral patterns are evaluated against known malware techniques.

Notice what that description does not depend on. It does not depend on the terminal showing a dialog. It does not depend on the terminal being Apple's. It does not depend on you having been warned. The check happens after the command starts running, by watching what the resulting processes do and where they reach out to. That is why this protection can cover software Apple did not write.

Protection 3: AppleScript and JXA scanning

The third protection integrates XProtect into the OpenScripting framework, which is the part of macOS that executes AppleScript and JavaScript for Automation, usually shortened to JXA. Scripts in both languages are scanned, and a match against a known malicious signature blocks execution and notifies the user.

There is an important asymmetry here, and Apple states it plainly: users may override blocks for file-based scripts, but cannot override scripts executed from memory. That distinction is not arbitrary. A script sitting in a file is something you can go and read before deciding. A script executed straight from memory, with no file on disk to inspect, is a pattern strongly associated with malware trying to leave nothing behind, and macOS simply will not let you push past it.

Scripting-based attacks on macOS have a long history, which is part of why this protection exists at all. Our broader look at current Mac malware families and how they get in covers how much of this ecosystem leans on scripting rather than exploiting software flaws.

Mapping the alert you saw to the protection that fired

Here is the quick orientation:

• You pasted into Apple's Terminal and got a warning before anything ran, with a way to proceed: Terminal Paste Protection.
• You pasted, something started, and then it was stopped, possibly in a third-party terminal: Pasteboard Command Blocking.
• The alert mentioned a script rather than a paste: AppleScript scanning, and whether you can override depends on whether that script was a file or ran from memory.

If you are not sure which happened, the next section goes through the individual alerts in more detail.

Decoding Each Alert

A note on wording before we start. Apple maintains a consumer support article titled If your Mac blocks a Terminal command paste or script at support.apple.com/en-us/127377, and that page is the canonical reference for the exact strings your Mac shows you. I was not able to read that page's body directly for this article, so the alert titles below are presented as the wording reported in press coverage, not as verbatim quotations from Apple. If what you saw differs slightly, trust your screen and Apple's article over any secondhand description, including this one.

What matters far more than the exact string is the category the alert falls into, and those categories are well documented.

Possible malware, Paste blocked

Press coverage reports this alert title for a heuristic match. Heuristic means macOS did not recognize a specific known threat. It recognized a shape of behavior that resembles how malicious pastes tend to work.

This alert is reported to offer a Paste Anyway option, with Apple warning that proceeding can still put your Mac and your privacy at risk.

Be honest with yourself about what that button means. It is not a button that says "macOS was wrong". It is a button that says "I am accepting responsibility for this". Because the match is heuristic rather than signature-based, false positives are genuinely possible, and a developer pasting an unusual but legitimate command may hit it. That is exactly why the override exists. But the same property that makes false positives possible also means the alert tells you nothing reassuring about the command itself. The system flagged a pattern. You now have to supply the judgment, and the decision rule further down this article is designed for precisely this moment.

The one thing you should never do is treat Paste Anyway as a formality to click through. If you find yourself reaching for it reflexively, stop and answer the questions in the decision rule section first. It takes half a minute.

Malware Detected, Paste Blocked

Press coverage reports this alert title for a match against a known malware signature, and reports that it comes with no override.

This is a categorically different message from the heuristic one. The heuristic alert says "this looks like the sort of thing that is usually bad". This one says "we have seen this before and we know what it is". There is no button because there is no reasonable scenario in which a normal user pasting a normal command should proceed past a confirmed known-threat match.

If you get this alert, the correct response is not to look for a workaround. It is to treat the source that gave you that command as hostile, close it, and move on to the containment steps if anything at all ran. Do not retype the command by hand to get around the pasteboard check. Do not try it in another terminal. Do not forward it to someone else to try. The command is not the problem you are solving; the page or message that gave it to you is.

Malicious Script Blocked

Press coverage reports this alert title for the third protection, the AppleScript and JXA scanning path. It appears when the OpenScripting framework is asked to run a script whose contents match a known malicious signature.

Whether you can override this one depends on where the script lives, and Apple documents the rule clearly. A file-based script can be overridden by the user. A script executed from memory cannot be, at all.

If you are seeing this while doing something legitimate, such as running an automation script you wrote or one shipped by software you trust, the override path for file-based scripts is there and you can use it. But do the obvious thing first and actually open the script file in a text editor. A script you can read is a script you can evaluate, and the entire reason macOS allows the override for files and not for memory is that the file case gives you that option.

What an override actually does

Overriding does not mark the command as safe. It does not teach macOS that you are a trusted user. It does not exempt you from the other protections. Specifically, clicking Paste Anyway on the Terminal warning does not disable pasteboard command blocking, which is a separate mechanism operating at the XProtect level after the process starts. You can override the warning and still have the resulting process blocked a moment later if it reaches for something known to be malicious.

That layering is a feature, not a redundancy. Each protection assumes the others might fail.

Why You Got the Prompt and Your Developer Friend Never Does

This is the single most common source of confusion around the paste warning, and the answer is documented rather than mysterious.

Apple's Platform Security documentation states that Terminal Paste Protection triggers only when all of the following hold:

• The user hasn't opened the Terminal app in more than 30 days.
• No common developer tooling is detected on the system.
• The paste originates from a specific app.

There is also a 24-hour grace period after initial setup, so a brand-new Mac being configured does not throw prompts at someone who is legitimately in the middle of setting up their environment.

Read those conditions again and notice what they describe. They do not describe a dangerous command. They describe a person.

The 30-day condition

If you use Terminal regularly, this protection is effectively invisible to you, because the first condition never holds. Opening Terminal within any 30-day window is enough to keep you outside the trigger. That is why developers, sysadmins, and anyone who lives in a shell can go the entire life of a Mac without seeing this dialog.

If you open Terminal roughly never, and today you are opening it because something told you to, you are exactly the person this condition is describing.

The developer tooling condition

The second condition looks for common developer tooling on the system. A machine with a real development environment on it belongs to someone who pastes commands as a normal part of their work, and warning that person on every paste would train them to dismiss the warning without reading it, which would make the protection worthless.

This condition also happens to be the honest answer for developers who find the prompt annoying, and we will come back to it in the troubleshooting section, because the fix is not what people usually ask for.

The source-app condition

The third condition is about where the pasted text came from. Apple describes the protection as covering pastes from common attack vectors: web browsers, Messages, Mail, Preview, and messaging apps. Text you copied from a document you wrote, or from another terminal window, is a different situation from text a web page or a stranger's message put on your clipboard.

That is a meaningful distinction, because ClickFix delivery is almost always through one of those channels. The command has to reach you somehow, and it reaches you through the apps you use to read things other people wrote.

Why this targeting is the right design

Put the three conditions together and you get a filter that fires for someone who does not normally use Terminal, has no development environment, and just copied a command out of a browser or a message. That is not a description of an unlucky power user. That is a description of a ClickFix victim, with high precision.

It also explains something that frustrates people: two users can paste the identical command and only one gets warned. Nothing about the command changed. The evaluation is about circumstances, not just content. If you want to understand what Terminal is actually for beyond this one alert, our complete guide to Terminal on macOS Tahoe is a reasonable place to start, and honestly, becoming a person who uses Terminal deliberately is a better long-term defense than any dialog box.

The iTerm2, Warp and Ghostty Question

Here is where most of the discussion goes wrong, and it goes wrong in a way that matters.

The common conclusion is: this only protects Apple's Terminal, so if I use iTerm2, I get nothing. That is half right and half wrong, and the distinction is probably the most useful thing in this article.

The paste prompt is specific to Apple's Terminal app. Apple's documentation describes Terminal Paste Protection as a warning shown when the user pastes into Terminal. iTerm2, Alacritty, Warp, Ghostty, Kitty, WezTerm and everything else will not show you that dialog unless their own developers implement something equivalent. If you live in iTerm2, you should not expect the warning, and you should not interpret its absence as an all-clear.

The pasteboard command blocking is not specific to Apple's Terminal. Apple's wording is explicit on this point: when a user pastes text into any terminal emulator, including third-party terminal applications, XProtect traces the resulting process tree and inspects its behavior. It is not watching the terminal's user interface. It is watching what the process the paste spawned actually does, and checking network artifacts against Apple's Safe Browsing Service while evaluating behavior against known malware techniques.

So the accurate way to state it: a third-party terminal user loses the warning but keeps the backstop. You lose the human-facing speed bump, the thing designed to interrupt you mid-social-engineering. You keep the machine-facing check that runs afterward.

That trade is worth understanding rather than shrugging at, because the two protections catch different failures. The warning catches you before anything runs, when the cost of being wrong is zero. The backstop catches the process after it has started, when the cost of being wrong is not zero, because some amount of code has already executed before the block lands.

There is also a practical implication for how you should behave. If you use a third-party terminal, you are the person for whom the decision rule below matters most, because your operating system is not going to interrupt you at the moment of the paste. You have to be your own dialog box.

None of this is a criticism of iTerm2 or Ghostty. They are excellent tools, and their users are typically the developer population that would be excluded from the paste warning anyway by the tooling condition. It just means the protection profile is different from what a lot of people assume, in both directions.

What ClickFix Actually Is

These protections exist because of a specific, extremely successful social engineering pattern. It is called ClickFix, sometimes described as pastejacking, and understanding it is more protective than memorizing any alert string.

The pattern is simple. A web page or message convinces you to copy a command and paste it into Terminal. The framing is almost always one of these:

• A fake verification step. You see something styled like a CAPTCHA or a human-verification challenge, but instead of clicking pictures of traffic lights, you are told to complete verification by running a command. This is the most common variant, and it works because verification challenges have trained everyone to follow odd instructions without questioning them.
• A fake error with a fix attached. A page tells you a component is missing, a codec is out of date, or a driver failed, and helpfully provides the command that resolves it. The error is fictional. The fix is the payload.
• A fake installer. A download page for real, desirable software presents a command as the quick install method, often alongside a normal-looking download button.
• A fake meeting-app update. You click a meeting link, get told your conferencing app needs an update before you can join, and are given a command to run. The time pressure of a meeting you are already late for does the rest.

Why it works on careful people

ClickFix is not a test of intelligence. It has three properties that defeat ordinary caution.

First, you perform the action yourself. No download is blocked, no Gatekeeper prompt appears, no unsigned app gets quarantined, because nothing was downloaded in the way those protections expect. You typed the attack in with your own hands. Many of the defenses Mac users rely on are watching a different door.

Second, the framing supplies a reason. Every variant answers the question "why am I doing this" before you ask it. Verification. A missing component. A faster install. People do not resist instructions that come with an explanation, especially a boring one.

Third, it borrows the authority of legitimate practice. Real software genuinely does ship paste-this-command instructions. The attack is not pretending to be something unusual. It is imitating something normal.

That last point is why a related family of attacks works too. Fake system dialogs asking for your password succeed for the same reason, which we covered in detail in our writeup on the fake Mac crash report password prompt. Same underlying trick, different surface.

The Microsoft Threat Intelligence research, and why it changes how you should evaluate links

Microsoft Threat Intelligence research reported on 2026-08-05 tracked a macOS ClickFix operation across more than 250 front-end domains. The scale alone is worth pausing on, but the mechanism is the important part.

According to that research, a small JavaScript snippet fingerprints each visitor before deciding what to show them. The reported signals include the platform string, screen and window dimensions, WebGL data, timezone, whether the page is in an iframe, and touch support. It also specifically hunts security researchers using a counter that increments while the browser developer console is open, a neat trick that turns the analyst's own tooling into a detection signal.

Visitors who do not match the target profile get blank pages or unrelated sites. Visitors who do qualify, meaning Mac users who look like real people, get a GitHub-themed page offering a Download for macOS option, complete with a forged Verified Publisher badge. The payloads reported in that research were MacSync and Atomic Stealer, commonly abbreviated AMOS.

Here is the consequence that actually changes your behavior, and it is worth stating bluntly:

Because the page shows different content to different visitors, "I checked it and it looked fine" is worthless as evidence. So is "my friend opened it and nothing happened."

You are not evaluating a fixed thing. You are evaluating something that decided what to be based on who was looking. A colleague who opened the link on a Windows machine, or in a browser with developer tools open, or from a different timezone, may have seen an entirely blank page and honestly reported that the link was harmless. That report tells you nothing about what you were shown.

The forged Verified Publisher badge deserves a mention too. Trust badges are pixels. Anything a legitimate site can display, a malicious site can copy exactly. A badge is a claim, not proof, and treating it as proof is the same category of mistake as trusting a password prompt because it looks like macOS drew it.

What Is Actually at Stake

It is easy to read all this as abstract, so here is what the malware on the other end of a successful ClickFix actually does.

Huntress research reported on 2026-08-06 described a Go-based macOS stealer delivered through ClickFix that impersonates legitimate macOS components. Its targets, as described in that research: browser password databases, the Apple Keychain, cookies, and credential files.

The Keychain is the whole point

Focus on the Keychain for a moment, because it defines the blast radius. Your login Keychain is not one password. It is Wi-Fi credentials, app credentials, certificates, secure notes, and for many people years of accumulated saved website logins. Anything that reaches the Keychain has not stolen a password. It has stolen the set.

That is why the honest advice after a suspected compromise is never "change the password you typed". Every credential that lived on that machine has to be treated as exposed.

The DRAIN function and the 1% design

The Huntress research also described a function named DRAIN in that stealer. It scans for Bitcoin, Litecoin, Dogecoin, Ethereum and XRP wallet formats, and it can transfer a share of the balance controlled by a DRAIN_PCT variable. That variable is configurable down to 1%.

Sit with that number. An attacker who empties a wallet gets caught immediately, because the victim notices and the incident starts. An attacker who takes 1% may never be noticed at all. The design is deliberately quiet, and it is optimized for staying resident rather than for a single large score.

The practical consequence for you: "my balance looks right" is not evidence that you are clean. A theft designed to be small enough to miss will, in fact, be missed. If you have reason to believe something ran on your Mac, do not use the absence of an obvious loss as an all-clear.

Three months

The Huntress research reported that one monitored Mac had been compromised roughly three months before detection.

Three months of browsing. Three months of logins, sessions, cookies, and whatever else passed through that machine. If you are trying to calibrate how urgent the runbook below is, that number is your calibration. These infections are not loud. Nothing pops up. The Mac does not get slow in a way you would notice. The entire business model depends on you not looking.

A Decision Rule You Can Actually Use

This is the practical heart of the article. You do not need to read shell syntax fluently to make a good decision here. You need to answer five questions honestly.

Question 1: Did I go looking for this, or did something tell me to run it?

This is the highest-signal question by a wide margin, and it costs you nothing to answer.

You went looking: you decided to install a specific tool, you navigated to that tool's documentation yourself, and you found an install command there. The intent originated with you.

Something told you: a page you landed on, an error you did not seek out, a message someone sent, or a verification screen produced the instruction. The intent originated elsewhere.

Nearly every ClickFix victim is in the second category. Nearly every legitimate paste is in the first. If you are in the second category, the default answer is no, and everything below is about whether you have enough reason to overturn that default.

Question 2: Do I know what every part of this command does?

Not the general gist. Every part.

If the answer is no, you have two options: learn what it does before running it, or do not run it. There is no third option where you run something you do not understand because a page assured you it was fine. If the command is long, obfuscated, base64-encoded, or full of characters you cannot explain, treat the obfuscation itself as the answer. Legitimate install commands are not usually trying to be unreadable.

Question 3: Does it pipe a download straight into a shell?

The shape to watch for is a command that fetches something from the network and immediately executes it, typically by piping the output of a download tool into sh or bash. This pattern means you are running code you have never seen, from a server, at the moment it arrives.

This pattern is not automatically malicious. Real projects use it, and we will deal with that honestly in the next section. But it does mean the code you execute is whatever that server decides to send you at that instant, which, given the Microsoft Threat Intelligence findings about visitor fingerprinting, is not necessarily what it sends anyone else.

Question 4: Does it ask for sudo and my password?

Running with sudo hands over administrator rights. That is not automatically wrong, since plenty of legitimate installers need it, but it changes the consequences of being wrong from bad to severe. Escalate your scrutiny in proportion. A command that wants root from a source you cannot vouch for is not a close call.

Related habit worth building: your admin password should be something you type in response to actions you initiated, never in response to a prompt that arrived on its own.

Question 5: Is the source the project's own documentation, reached by my own navigation?

The strongest signal is the combination of two things: the instruction lives on the software project's own site or repository, and you got there by navigating yourself rather than by following a link someone handed you.

That combination matters because either half alone is weak. A page can look exactly like a project's documentation. A link can point anywhere while displaying anything. Typing the project name into a search yourself, checking the domain matches the actual project, and finding the install instructions in the documentation where they belong is a meaningfully different act from clicking through to a page that told you what to run.

How to read a command before you run it

If you have decided a command is probably legitimate but you want to verify rather than hope, here is the approach.

Paste it into a text editor, not Terminal. A plain text editor executes nothing. This immediately breaks the pattern the attack depends on, which is that you paste into a place where pressing Return runs it.

Look at the whole thing, including what scrolled off. A genuinely nasty trick is a command padded with whitespace or newlines so that what you see is innocuous and the payload sits far to the right or on a following line. A text editor with word wrap on shows you everything. Terminal does not.

Check for a trailing newline. If the copied text ends with a newline, pasting it into a shell executes it immediately with no chance to read it. This is a deliberate technique. It is also a reason the paste warning exists.

For a download-and-execute installer, split the steps. Instead of piping a download directly into a shell, download the script to a file, open that file in a text editor, read it, and only then run it. This costs you about ninety seconds and converts an act of faith into an act of inspection. If the script is thousands of lines of dense logic you cannot evaluate, you have at least learned something real about how much trust you are extending.

Decode anything encoded. If part of the command is base64 or hex, decode it and read the result rather than running it. If a legitimate installer needs to hide its own contents from you, that is worth a question.

When in doubt, do not. The cost of not running a legitimate command is that you install something a slower way. The cost of running a malicious one is in the previous section.

Why Homebrew-Style Installers Look Identical to the Attack

Time to be honest about the uncomfortable part, because pretending otherwise would make this article useless.

The reason this is genuinely hard is that the legitimate pattern and the attack pattern are the same shape. Homebrew's installer is the canonical example: the officially documented way to install it is to paste a command into your terminal that downloads a script and runs it. Homebrew is not doing anything wrong. It is a widely used, widely trusted project, and that installation method has been standard practice for over a decade. Plenty of other respectable tools do the same.

So any advice that amounts to "never paste commands into Terminal" is advice that would have you not install Homebrew, and people correctly ignore it. The absolutist version of this rule fails because it contradicts everyday legitimate practice, and rules that people cannot follow do not protect anyone.

What actually separates the two cases is not the command. It is the context around it.

How you arrived at the instruction. With Homebrew, you decided to install Homebrew, went to the Homebrew site, and read the install instructions. With ClickFix, a page you did not seek out told you to run something to solve a problem you did not know you had until that page said so. The direction of intent is reversed, and that reversal is the tell.

Whether the domain is the project's own. The command should live on the project's actual site or its actual repository. Not a mirror, not a blog post, not a shortened link, and not a page whose branding merely resembles the project's. Verify the domain by looking at it rather than by looking at the page's logo. The Microsoft Threat Intelligence research described a GitHub-themed page carrying a forged Verified Publisher badge, which is a precise illustration of why visual branding is not verification.

Whether the command matches published, corroborated instructions. Independently look up the project's install command. If what you were handed differs from what the project publishes, you have your answer, and you did not need to understand a single character of shell syntax to get it.

Whether the framing involves urgency or verification. Legitimate install docs do not tell you that you must run something to prove you are human, or that a meeting will not start until you do. Urgency and verification framing are almost purely an attacker signal.

Put simply: Homebrew's command is safe not because of what the command says, but because of where you found it and how you got there. Apply the same standard to everything else and you will get most of these calls right.

What to Do If You Already Pasted and Ran Something

If a command already ran, work through this in order. Do not try to do everything at once, and do not skip to the dramatic step at the end.

1. Disconnect that Mac from the network. Turn off Wi-Fi, unplug Ethernet. Stealers exfiltrate over the network, so cutting the connection limits what can still leave. This is the one step where speed genuinely matters.

2. Do not panic-reboot, and do not start deleting things at random. A reboot does not remove persistence and may destroy useful evidence about what happened. Take a breath. The next steps matter more than the next sixty seconds.

3. Change your passwords from a different, trusted device. This is the step people get wrong, and getting it wrong undoes the rest. If you change your passwords on the possibly-compromised Mac, you are typing the new passwords into the machine that may still be watching. Use a phone, a tablet, or another computer that never touched the incident. Order matters: Apple Account first, then your password manager's master password, then email, then financial accounts, then everything else.

4. Treat everything in your Keychain as exposed and rotate it. Huntress described the Apple Keychain as an explicit target. That means Wi-Fi passwords, app credentials, saved logins, and secure notes. It is tedious. Prioritize anything that protects money, identity, or access to other accounts.

5. Revoke active sessions everywhere you can. Stolen cookies let an attacker skip your password entirely, so changing a password without ending existing sessions can leave the attacker logged in. Most major services have a "sign out of all devices" or active-sessions control. Use it after you change each password.

6. Move crypto to a new wallet with a seed generated on a clean device. If a wallet was on that Mac, the seed is compromised, and generating a new wallet on the same machine reproduces the problem. Generate on a device you trust, then move funds. And, per the DRAIN_PCT design described by Huntress, do not let a correct-looking balance talk you out of this.

7. Check Login Items and background items. In System Settings, under General, review Login Items and the background items list for anything you do not recognize or cannot account for.

8. Check for configuration profiles. In System Settings, under General and then Device Management, look for profiles you did not install. A profile you did not put there is a serious finding, since profiles can change system behavior broadly.

9. Run a reputable scanner. A scanner is useful for catching known families and as a second opinion, though it is weakest against genuinely novel payloads. Our guide to antivirus options for Mac covers what these tools realistically do and do not catch.

10. Understand that only a wipe truly resolves it. This is the honest part. Erasing the Mac and reinstalling macOS, then restoring data from a backup that predates the incident, is the only remediation that genuinely returns you to a known-good state. Anything less is you deciding the cleanup was probably thorough enough. Be careful with restores: restoring applications or system settings from a post-incident backup can carry the problem straight back over. Restore documents; reinstall applications from their sources.

11. Watch your accounts for longer than feels necessary. Given that a monitored Mac in the Huntress research went roughly three months before detection, one quiet week means very little. Keep an eye on financial accounts and email forwarding rules, which are a favorite persistence trick, for a good while afterward.

If working through that list left you wanting a broader hardening pass, our Mac security and privacy guide covers the settings worth changing while nothing is on fire.

What These Protections Do Not Cover

Being clear about the limits is not pessimism. It is the difference between a defense you can rely on and a false sense of security that gets you hurt.

They are not antivirus. These are targeted protections aimed at one delivery technique. They are not a general-purpose malware scanner, they do not monitor your whole system continuously in the way a security product does, and they were never designed to.

They do not inspect what you type by hand. Terminal Paste Protection is about pasting. If an attacker convinces you to type a command manually, one character at a time, the paste warning has nothing to act on. Pasteboard command blocking still watches the resulting process behavior, but the human-facing speed bump is gone.

They do not help with a normally downloaded installer. If you download a DMG or PKG and run it in the ordinary way, you are in Gatekeeper and notarization territory, not Terminal paste territory. Those are different mechanisms with different failure modes, which we covered in our piece on the app is damaged error and Gatekeeper quarantine.

A novel attack will not match a known signature. Signature matching by definition catches what has already been seen. The behavioral evaluation and Safe Browsing checks extend that reach, but a genuinely new payload using genuinely new infrastructure can slip through all of it. Absence of a warning is not evidence of safety.

The paste warning does not fire for most people. By design. The documented conditions exclude anyone who has opened Terminal in the past 30 days or has developer tooling installed. If you are a developer who assumed this protection has your back, it does not, and that is intentional.

Third-party terminals do not show the warning. Covered above, but worth repeating in a limits section, because it is the assumption most likely to hurt someone.

None of it addresses the root cause. The root cause is that a stranger persuaded you to run their code. Software can interrupt that. It cannot decide for you.

Troubleshooting Common Issues

A legitimate install command is being blocked

Problem: You are installing real software from its official documentation, and the paste is blocked or warned about.

Solution: First, confirm the legitimacy independently rather than assuming it, since the whole point of the attack is that it feels legitimate. Search for the project yourself, navigate to its official site or repository, and compare the published install command to the one you have. If they match and you reached the docs by your own navigation, this is likely a heuristic false positive and the override exists for exactly this case. If the alert offers no override, do not work around it, because a no-override alert indicates a known-threat match rather than a heuristic guess. Consider installing through the project's package or installer instead of the paste method.

The alert has no override button

Problem: There is no Paste Anyway option and no obvious way to proceed.

Solution: Treat this as the intended outcome, not a bug. Press coverage associates the no-override alert with a known-malware signature match, and Apple documents that scripts executed from memory cannot be overridden at all. Do not retype the command by hand, do not try a different terminal, and do not disable anything. Close the source that gave you the command and treat that source as hostile. If any part of it ran before the block landed, start the runbook above, beginning with disconnecting from the network.

The alert keeps appearing for the same command

Problem: You dismiss the alert, try again, and it comes back every time.

Solution: These protections do not maintain a per-command allowlist, so there is no remembered decision to accumulate. Repeated alerts mean repeated evaluation reaching the same conclusion, which is information, not malfunction. If it is the heuristic warning and you have verified the source properly, the override is per-attempt. If it is the known-threat alert, repetition is the system telling you the same true thing again. If you genuinely need the software, install it a different way: a signed installer package, a package manager you already trust, or the App Store version if one exists.

Nothing pasted at all and you are not sure whether it was blocked

Problem: You pressed Command-V, nothing appeared, and no alert is visible.

Solution: Rule out the boring causes first. Confirm Terminal actually has keyboard focus, confirm the copy succeeded by pasting into a plain text editor, and check whether an alert opened behind another window or on another display. If the text pastes fine into a text editor but not into Terminal, a protection is a reasonable suspect, and the text editor now gives you the chance to read what you were about to run. Read it there before trying again. If the paste worked but nothing seemed to happen after you pressed Return, treat that as possible pasteboard command blocking and check Activity Monitor for unfamiliar processes.

You are a developer and want the prompts to stop

Problem: The paste warning is interrupting normal work.

Solution: Honestly: Apple does not expose a user-facing switch for these protections, and this article is not going to describe a way to defeat them. The documented behavior already solves your problem, though. The paste warning only triggers when the user has not opened Terminal in more than 30 days and no common developer tooling is detected and the paste came from a specific app. If you are hitting it regularly, the useful question is why your machine does not look like a development machine to the system. Having normal developer tooling present, and using Terminal as part of your regular workflow, is the intended path out of the prompt, not a hidden preference.

You already clicked Paste Anyway and now regret it

Problem: You overrode the warning, the command ran, and afterward you started doubting the source.

Solution: Go to the runbook above and start at step one, disconnecting the Mac from the network. Do not wait for a visible symptom, because the malware described in the Huntress research was specifically designed not to produce one, including a crypto-draining function tunable down to 1% of a balance. Change credentials from a different device first. Overriding the warning does not disable pasteboard command blocking, so it is possible the process was stopped afterward anyway, but you should not assume that without evidence.

FAQ

Which macOS versions have these protections?

Apple's Platform Security documentation describes Terminal Paste Protection, pasteboard command blocking, and AppleScript scanning as introduced in macOS 26.4 or later. Earlier versions do not have them. If you are running something older and paste commands into Terminal, none of the behavior described here applies to your machine.

Does this work in iTerm2, Warp, or Ghostty?

Partly. Apple documents the paste warning as a Terminal app feature, so third-party terminals do not show it unless their developers build something equivalent. But Apple states that pasteboard command blocking covers any terminal emulator, including third-party applications, because XProtect traces the resulting process tree. You lose the warning, you keep the backstop.

Can I turn these protections off?

Apple does not expose a user-facing switch for them, and this article will not describe workarounds. If you are a developer hitting false positives, the documented trigger conditions are your answer: the paste warning does not fire on machines with common developer tooling present or where Terminal has been opened in the past 30 days.

Is Paste Anyway ever the right choice?

Yes, in one situation: you sought out the software yourself, reached its official documentation by your own navigation, and the command matches what the project publishes. That is a real false-positive scenario and the override exists for it. If a page you did not go looking for handed you the command, the answer is no.

If nothing was blocked, does that mean the command is safe?

No. These protections catch known signatures and recognized behavioral patterns, so a genuinely novel attack using new infrastructure can pass through without triggering anything. Silence is not an endorsement. The decision rule in this article, particularly the question of whether you went looking for the command, remains your primary defense.

How would I even know if something got through?

Often you would not, which is the uncomfortable part. Huntress reported a monitored Mac compromised roughly three months before detection, and described a crypto-draining function configurable down to 1% specifically so victims do not notice. Check Login Items, configuration profiles, and account sessions rather than waiting for a symptom.

Conclusion

Your Mac blocked a paste. That is a small, boring event that occasionally turns out to have been the most important thing that happened to your machine that year.

The useful mental model is layers. Terminal Paste Protection is the human layer, a deliberately narrow interruption aimed at people who do not normally use Terminal and just copied something out of a browser or a message. Pasteboard command blocking is the machine layer, working at the XProtect level on the resulting process tree across any terminal emulator, including third-party ones. AppleScript and JXA scanning covers the scripting path, with overrides available for file-based scripts and none at all for scripts run from memory. Each layer assumes the others might fail, which is the correct assumption.

But the protections are narrow, and the honest summary of their limits is that they are not antivirus, they do not read what you type by hand, they do not catch a novel payload with no known signature, and by design they will never fire for most developers. The attack they exist to stop, meanwhile, is well funded and well engineered. Microsoft Threat Intelligence reported more than 250 front-end domains fingerprinting visitors and hunting researchers. Huntress described a stealer targeting the Apple Keychain with a theft function tuned to stay under the threshold of notice.

Which brings it back to the one thing software cannot do for you. Before you paste anything into a terminal, answer one question: did I go looking for this command, or did something tell me to run it? If you went looking, verify the domain is the project's own and the command matches what the project publishes, then proceed. If something told you, the default is no, and the burden of proof is on the thing that told you. That question takes five seconds, it works on every variant of this attack, past and future, and it does not require you to read a line of shell.

If a command already ran, do not spiral about it. Disconnect from the network, change your credentials from a different device, rotate everything in the Keychain, move any crypto to a wallet generated on a clean machine, and plan the wipe. The attack is designed to be convincing. Falling for it is not a character flaw, and the recovery is a list, not a catastrophe.

Related reading: Fake Mac Crash Report Asking for Your Password? Do Not Type It