What Is ClickFix, and How Do I Stop Staff and Developers Falling for It?

ClickFix is a social engineering trick that gets a person to copy a command from a web page and run it themselves, usually in the Windows Run dialog, PowerShell or the macOS Terminal. Because the victim launches the command, it skips most download and email checks. Stop it with one training rule, application control, logging, and short lived developer credentials.

Below: each stage of the attack, why it works on technical people, what the new browser and operating system warnings cover, which endpoint settings are worth the friction, and how to protect the developer tokens ClickFix usually goes after.

Key takeaways

• ClickFix is catalogued by MITRE ATT&CK as T1204.004, "Malicious Copy and Paste", a form of user execution on Windows, macOS and Linux. The attacker never runs code directly. The victim does.
• The lure is always a fake problem with a fake fix: a CAPTCHA, a browser error, a repository "security alert", or a fake install guide for a developer tool.
• It works because the payload arrives as text on the clipboard, not as a downloaded file. Download scanning, attachment filtering and browser sandboxing mostly never see it.
• Chrome added a ClickFix warning to Enhanced Protection on 20 October 2026, and macOS Tahoe 26.4 added a Terminal paste warning in March 2026. Both help. Neither covers everyone, and neither is documented in enough detail to rely on.
• The controls that hold up are boring: application control that forces PowerShell into Constrained Language mode, removing the Run dialog for staff who do not need it, PowerShell script block logging, and alerting on a browser that spawns a shell.
• One sentence for training: "No real website, CAPTCHA, recruiter or support page will ever ask you to paste something into Run, PowerShell or Terminal."
• On developer machines, assume the goal is tokens. Move package publishing to short lived OIDC credentials, cut long lived tokens off disk, and be ready to find every project that pulled a bad version if a stolen token is used to publish one.

What is a ClickFix attack, step by step?

MITRE describes the technique plainly: adversaries trick users into copying and pasting code, often through fake error messages or CAPTCHA prompts, and the pasted command "typically" establishes a foothold. The Cyber Security Agency of Singapore described the same pattern in its July 2025 alert as a three step routine: open the Run dialog, paste a command that has often already been placed on the clipboard, and run it.

Here is the chain in plain language. No step needs an exploit.

A few details make this harder to spot than it looks on paper.

The visible text and the clipboard are not the same thing. In the GitHub themed campaign that the SANS Internet Storm Center analysed in September 2024, the pasted command was disguised so that the part the user could see in the Run box looked like a reCAPTCHA verification ID. The rest was pushed out of view. In October 2026, BleepingComputer reported a fake Claude download page for macOS that displayed Anthropic's real install command on screen while its copy button put a different command on the clipboard. Reading the page, the victim would have seen the right thing.

The paste target keeps moving. Beyond the Run dialog, lures point at PowerShell or the macOS Terminal. The "FileFix" variant, credited to the researcher mr.d0x and covered by BleepingComputer in October 2025, asks the victim to paste what looks like a file path into the File Explorer address bar. Padding hides the real command, and Windows runs it when the user presses Enter. The same BleepingComputer report described "cache smuggling", where the browser caches a file labelled as an image that is actually an archive, so no explicit download ever happens.

The tools used are already on the machine. PowerShell, mshta, certutil, curl or the shell fetch the second stage.

State actors use it too. MITRE's procedure examples list Contagious Interview, Kimsuky and MuddyWater using ClickFix style lures.

Why does ClickFix bypass download protection and email filters?

Most of the controls companies have built over the last fifteen years look for files: attachment filtering, browser download checks, scanning of new executables, and Mark of the Web tags on downloads.

ClickFix sends none of that. MITRE says it directly: because the user runs the command, the technique "can bypass" email filtering, browser sandboxing and other controls aimed at downloaded files. Google made the same point when it announced the Chrome change in October 2026. As 9to5Google quoted it, moving the download "into the terminal" lets attackers "completely sidestep existing Chrome and Safe Browsing download protections."

Break it down by layer:

So an analyst who visits a reported page directly may see nothing at all.

How are developers targeted?

Developers are an unusually good target for ClickFix, for three reasons. Pasting a command into a terminal is part of their normal day. Their machines hold credentials that reach source code, CI and package registries. And a lot of legitimate tooling is installed with a one line curl ... | bash or irm ... | iex command, so a request to paste one does not feel odd.

The lures that reach developers fall into a few groups.

Fake security alerts on repositories

In September 2024, attackers opened issues on public repositories claiming the project had a security vulnerability. Every watcher got an email from GitHub's real notification address, signed as the "GitHub Security Team". The link went to a third party "scanner" site with a fake CAPTCHA. SANS handler Johannes Ullrich noted that GitHub does not deliver scan results that way. The CAPTCHA copied a hidden PowerShell command, and the payload was identified as the Lumma Stealer infostealer.

The lesson is that a notification from a legitimate service does not make the content legitimate. Anyone who can open an issue can make GitHub send an email.

Fake install guides for developer tools

This is the variant that has grown most in 2026, because AI coding tools are new, popular and installed from the terminal. BleepingComputer reported on 9 October 2026 that a Google search ad for "claude mac" displayed a legitimate bing.com domain, passed through Google's and Bing's redirectors, hopped through a compromised retail site, and landed on a fake Claude download page. The page showed Anthropic's real one line installer, but the copy button swapped in a different command that printed a reassuring message and ran a downloaded file through zsh. BleepingComputer said it was unclear what payload, if any, was ultimately installed.

The attacker never needs to touch Anthropic's or any other vendor's infrastructure. They only need to rank above the real docs for a few hours.

For contrast, Anthropic's own setup page lists the native installer, Homebrew (brew install --cask claude-code), WinGet (winget install Anthropic.ClaudeCode), signed apt, dnf and apk repositories, and npm. It also documents how to verify a release: a GPG signed manifest.json with SHA256 checksums, Apple notarisation on macOS (codesign --verify --verbose) and Authenticode on Windows (Get-AuthenticodeSignature). A package manager or a verified binary is a much harder thing to fake than a web page with a copy button.

Poisoned issues, docs and READMEs

The same idea works anywhere a developer looks for a fix: an issue comment that says "run this to fix the build", a forum answer, a gist, or a README in a lookalike fork. The command is usually encoded so a glance does not reveal what it does.

Fake job interviews

MITRE lists the Contagious Interview group as a user of ClickFix style lures. Contagious Interview is the name given to fake recruitment campaigns aimed at developers. The commonly reported pattern is a "recruiter" who invites a developer to an online assessment, something on the page "fails", and the candidate is given a command to fix it. The pressure of a job interview does the rest.

Why AI coding agents change the picture a little

An agent that reads a poisoned issue or README and runs the "fix" it finds is ClickFix without a human in the loop, which is why agents should ask before every command on unfamiliar repositories. See is it safe to open an untrusted repo with an AI coding agent and is Claude Code safe to use at work.

What does Chrome's new protection catch, and what does it miss?

Google announced the change on 20 October 2026. According to The Hacker News and BleepingComputer, when an Enhanced Protection user copies something that looks like a ClickFix script, Chrome scrubs personal information from it and sends it to Safe Browsing. If the verdict is dangerous, Chrome warns before the user runs it. The same update moved Gemini based scam page detection to the server side and added a softer "suspicious site" warning. Google says off device content is processed ephemerally and not logged or used for training, and that Enhanced Protection makes users "ten times safer" than Standard Protection, a figure it has not explained.

What it does not cover, or does not say:

Turn it on anyway. In Chrome it lives under Settings, Privacy and security, Security, Enhanced protection. For a managed fleet, Chrome's enterprise policy SafeBrowsingProtectionLevel set to 2 enforces Enhanced Protection. Just do not write a policy that assumes it will catch everything.

The macOS Terminal warning

Apple added a paste warning to Terminal in macOS Tahoe 26.4, reported by BleepingComputer on 30 March 2026. When a user pastes something macOS judges risky, Terminal holds it and warns, and the user can cancel or proceed. Apple has not documented how it decides what is risky, and user reports relayed by BleepingComputer suggest it may fire only once per session and mainly on content copied from Safari. It is unclear whether third party terminals are covered. Treat it as a speed bump, not a control.

Which endpoint controls help?

No single setting stops ClickFix, but a few remove most of the easy wins. Order them by how much breakage they cause.

Remove the Run dialog for staff who do not need it

The Group Policy setting "Remove Run menu from Start Menu" (User Configuration, Administrative Templates, Start Menu and Taskbar) removes the Run command from the Start menu and the "New Task (Run)" command from Task Manager, and stops the Windows+R shortcut from opening the Run dialog. Microsoft's own description is honest about the limit: the policy "does not prevent users from using other methods to run programs." So it blunts the classic "Windows+R, Ctrl+V, Enter" script and nothing else.

It suits finance, sales, support and front desk staff. It is a poor fit for developers and IT. Pilot it first; community write ups report Explorer side effects that Microsoft's page does not mention.

Put PowerShell into Constrained Language mode, properly

PowerShell has four language modes. In ConstrainedLanguage, cmdlets still work, but scripts cannot load arbitrary C# through Add-Type, cannot call most .NET types, and cannot create most COM objects. That breaks a large share of the obfuscated loaders that ClickFix commands use, without breaking ordinary administration.

Microsoft says setting the mode by hand is only useful for experiments. To stick, it must come from an application control policy: PowerShell detects App Control for Business (formerly WDAC) and AppLocker and runs untrusted code in Constrained Language mode under them. Microsoft's docs say to use System Lockdown mode with App Control so the mode cannot be bypassed, and that it is no longer investing in AppLocker.

Since PowerShell 7.4, App Control audit mode logs would be violations instead of failing scripts, which is the safe way to roll it out.

Turn on PowerShell script block logging

Script block logging records the content of PowerShell code as it runs, after it has been decoded. That is what you want for ClickFix, where the pasted text is usually encoded. Events land in the Microsoft-Windows-PowerShell/Operational log with event ID 4104. Without it, an investigator often only sees "powershell.exe started" and a parent process.

Alert on the right process chain

MITRE's detection guidance for T1204.004 describes behaviour rather than strings: a user active in a browser, mail client or Office app, then a command interpreter launched with suspicious arguments, optional files dropped in temp folders, and an outbound connection, all in the same session. It gives equivalent patterns for Linux and macOS terminals piping downloads or base64 into a shell.

Two rules catch a lot: explorer.exe (which hosts the Run dialog) launching powershell.exe, mshta.exe, cmd.exe or certutil.exe with network arguments, and on macOS, Terminal or iTerm2 spawning curl piped to a shell for a URL that is not on your list of known installers.

Control matrix

Step by step: harden Windows and Mac endpoints against ClickFix

Here is a practical rollout. Try each step on a pilot group first.

Step 1: Check where you are today

On Windows, see which PowerShell language mode a normal user gets:

$ExecutionContext.SessionState.LanguageMode

FullLanguage means no application control is constraining PowerShell; ConstrainedLanguage means a policy is in force.

Check whether the Run dialog is already restricted for the current user:

Get-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer' -Name NoRun -ErrorAction SilentlyContinue

On macOS, check the version, since the Terminal paste warning needs Tahoe 26.4 or later:

sw_vers -productVersion

Step 2: Remove the Run dialog for non technical groups

Use Group Policy: User Configuration, Administrative Templates, Start Menu and Taskbar, "Remove Run menu from Start Menu", set to Enabled, linked to an organisational unit that holds non technical staff. The policy writes a NoRun value of 1 under the Explorer policies key. For a single test machine you can set it directly:

New-Item -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer' -Force | Out-Null
New-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer' -Name NoRun -Value 1 -PropertyType DWord -Force

Sign out and back in, then press Windows+R to confirm nothing opens.

Step 3: Turn on script block logging

Through Group Policy: Computer Configuration, Administrative Templates, Windows Components, Windows PowerShell, "Turn on PowerShell Script Block Logging". On a test machine, from an elevated prompt:

$key = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging'
New-Item -Path $key -Force | Out-Null
Set-ItemProperty -Path $key -Name EnableScriptBlockLogging -Value 1

Then confirm events arrive:

Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-PowerShell/Operational'; Id = 4104 } -MaxEvents 5 |
  Select-Object TimeCreated, Message

Forward these to your log platform, and restrict who can read them, since script blocks can contain secrets.

Step 4: Deploy App Control in audit mode, then enforce

Build an App Control for Business policy that allows signed Microsoft and approved line of business code. Deploy it in audit mode. On PowerShell 7.4 and later, untrusted scripts run in Constrained Language mode but log what would have been blocked instead of failing. Review those events for a few weeks, sign or allow the internal scripts that need full language, and then switch to enforce. After enforcement, re-run Step 1 as a standard user and expect ConstrainedLanguage.

Step 5: Give developers a trusted install path

Publish an internal page with the approved install method for each common tool, preferring package managers with signature checks over web one liners. Anthropic documents these for Claude Code:

# macOS with Homebrew
brew install --cask claude-code

# Windows with WinGet
winget install Anthropic.ClaudeCode

If a developer does use a direct download, verify it. On macOS, Anthropic's docs say binaries are signed by "Anthropic PBC" and notarised by Apple:

codesign --verify --verbose ./claude

On Windows:

Get-AuthenticodeSignature .\claude.exe

For any tool: bookmark the vendor's docs, never install from an ad or a shared chat, and read a one liner's script before running it.

Step 6: Make "paste into an editor first" the developer habit

A swapped clipboard is only dangerous if the paste goes straight into a shell. Pasting into a text editor first shows the full command, including anything hidden by padding or line breaks. Some shells can help: in zsh, bracketed-paste is on by default in recent versions, so a pasted multi line block does not run until you press Enter, which gives you a moment to read it.

Step 7: Move package publishing off long lived tokens

This step most limits the damage if a laptop falls. npm trusted publishing lets CI publish with short lived OIDC credentials instead of a token in ~/.npmrc or a CI secret. It supports GitHub Actions and GitLab.com hosted runners and CircleCI cloud, and needs npm CLI 11.5.1 and Node 22.14.0 or later:

name: publish
on:
  release:
    types: [published]

permissions:
  contents: read
  id-token: write

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22.14.0'
          registry-url: 'https://registry.npmjs.org'
      - run: npm install -g npm@latest
      - run: npm ci
      - run: npm test
      - run: npm publish

Add the trusted publisher in the package settings on npmjs.com. Once it works, npm recommends setting Publishing access to "Require two-factor authentication and disallow tokens" and revoking unused automation tokens. Public packages from public GitHub or GitLab repositories get provenance automatically.

Clean up old tokens:

npm token list
npm token revoke <token-id>

PyPI, RubyGems and crates.io offer comparable trusted publishing flows; use them where your packages live.

Step 8: Shrink what an infostealer can find on disk

Make an inventory of long lived credentials on developer machines. A quick check:

ls -la ~/.npmrc ~/.pypirc ~/.aws/credentials ~/.docker/config.json \
       ~/.config/gh/hosts.yml ~/.kube/config ~/.netrc 2>/dev/null

For each file that exists, ask whether it needs to. Prefer single sign on for cloud CLIs, expiring fine grained tokens for Git hosting, and keychain backed credential helpers over plain text files.

What should staff training say in one sentence?

"No real website, CAPTCHA, recruiter, support agent or security alert will ever ask you to paste something into Run, PowerShell or Terminal; if one does, stop and report it."

It is about the action, not the lure. Lures change every week; the action they need does not. CSA Singapore's advice makes the same point about unexpected Run dialog instructions.

For developers, add: "Install tools only from the vendor's docs or a package manager, and read any command in an editor before you run it."

Show a short screen recording of a real fake CAPTCHA, and tell people that reporting gets their machine checked, not them in trouble. Reports go up when that is clear.

What does a ClickFix infection usually steal, and why are developer tokens the prize?

The payloads named in public advisories are mostly infostealers and remote access tools. CSA Singapore's July 2025 alert lists DCRAT, NetSupport RAT, Latrodectus and Lumma Stealer, and warns of credential theft, data exfiltration, email account compromise and possible ransomware. The SANS analysis of the GitHub themed lure identified Lumma Stealer. An infostealer typically takes saved browser passwords and session cookies (which can skip multi factor prompts), files from common folders, wallet data, and credential files for developer tools. That last group is why developers are the prize. A single laptop often holds:

A stolen publish token turns one infected laptop into a supply chain incident. The attacker publishes a new version of a legitimate package with a malicious install script, and every project with a loose version range picks it up on its next install. This is the same shape as the npm worm incidents of 2025 and 2026; see the Shai Hulud npm supply chain attack explained and the tensorlake npm compromise. A stolen Git token lets an attacker edit CI workflows. Stolen cloud credentials skip the software supply chain altogether.

If someone already ran a ClickFix command

Treat it as a credential compromise, not a malware cleanup.

1. Isolate the machine, but keep it for evidence.
2. On Windows, capture the Run dialog's short history:

Get-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU'

3. Pull PowerShell event 4104 entries from that window; on macOS and Linux, read the user's shell history.
4. From a clean device, revoke and reissue everything the machine could reach: SaaS sessions, Git tokens and SSH keys, registry tokens, cloud and Kubernetes credentials, AI API keys. Revoke sessions, not just passwords.
5. Check registries and the Git host's audit log for unfamiliar publishes, tokens, deploy keys and workflow edits.
6. If a bad version was published, find every project and image that pulled it, pin away, rebuild and redeploy. See our incident response playbook for a compromised dependency.
7. Reimage the machine.

Where Safeguard fits, and where it does not

Safeguard's fit here is indirect. It does not stop ClickFix. It is not an endpoint, browser or email product, and it will not see the fake CAPTCHA, block the paste or detect an infostealer. Where it helps is the supply chain side of the blast radius.

• Knowing where a version is. If a stolen token is used to publish a bad version of a package you use, the first question is where it is. Safeguard scans repositories, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>), and the platform shows which projects contain a given component and version.
• Keeping a version out once you know it is bad. Policies and gates evaluated in the platform let a version your team has decided to block fail builds instead of quietly coming back.
• Fixing what is behind. Vulnerability matching and reachability analysis rank what is actually called, and autonomous remediation (off by default) opens tested fix pull requests.
• An assistant that asks before it runs commands. The Safeguard CLI's assistant edits code and runs commands with your approval, governed by its /permissions modes (Ask, Accept edits, Plan, Auto as the default, and Strict). Seeing each command before it runs is the opposite of the ClickFix pattern. safeguard exec covers CI.

It does not rotate tokens, revoke sessions or watch your registries for unexpected publishes. Those stay with your identity provider, registry settings and runbooks.

Common mistakes

• Training on lures instead of the action. People learn to spot last month's fake CAPTCHA and fall for this month's fake install guide. Teach the one action that is always wrong.
• Assuming the browser will catch it. Chrome's new check only works with Enhanced Protection on, and macOS's Terminal warning is undocumented. Neither covers lures outside the browser or typed commands.
• Setting Constrained Language mode by hand or with an environment variable. Microsoft's docs say that is only useful for experiments. Without App Control in System Lockdown mode, it can be bypassed.
• Removing the Run dialog and calling it done. The policy does not stop PowerShell, Terminal or the File Explorer address bar variant.
• Cleaning the malware and forgetting the tokens. The infostealer's job is finished in seconds. Rotating credentials and revoking sessions is the real response.
• Long lived publish tokens on laptops. A single stolen ~/.npmrc can publish to every package the developer maintains.
• Trusting a notification because the sender is real. GitHub sent the fake vulnerability alerts in 2024 from its real address because an attacker opened an issue.
• Visiting the reported URL directly and closing the ticket. Cloaked pages show nothing to direct visits. Ask the user how they arrived.

FAQ

What is ClickFix in simple terms?

A scam where a web page shows a fake problem, such as a CAPTCHA or an error, and tells you to fix it by pasting a command into Run, PowerShell or Terminal. The command installs malware, and because you ran it yourself, download protection does not stop it.

Is ClickFix a virus?

No. It is a delivery technique, tracked by MITRE as T1204.004. The pasted command fetches the real malware, usually an infostealer or remote access tool.

How do I know if a CAPTCHA is fake?

A real CAPTCHA only asks you to click or pick images in the browser. If a "verification" asks you to press Windows+R, open Terminal or PowerShell, or paste anything, close the tab.

What is the "verification code" a ClickFix page asks me to paste?

It is a command, arranged so the visible part looks like an ID while the rest sits off screen. If you ran it, report it and treat the machine as compromised.

Does Chrome protect me from ClickFix now?

Partly. Since 20 October 2026, Chrome warns Enhanced Protection users when they copy a command Safe Browsing judges dangerous. Standard Protection users, other browsers, lures outside the browser and typed commands are not covered.

Does ClickFix work on Mac and Linux?

Yes. MITRE lists Windows, macOS and Linux. Mac lures usually ask for a Terminal paste, often posing as a developer tool install guide.

Can antivirus or EDR stop ClickFix?

Sometimes, at the payload stage, which is late. Pair it with application control, Constrained Language mode, script block logging and alerts on a browser session followed by a shell making network calls.

Should I disable PowerShell to stop ClickFix?

Usually not. Running untrusted PowerShell in Constrained Language mode under App Control gets most of the benefit with far less breakage.

What should I do if I ran a ClickFix command?

Disconnect, tell your security team, and from a clean device sign out of all sessions and reset key passwords. Developers should also revoke Git, registry, cloud and API tokens.

Why do attackers target developers with ClickFix?

Developers paste terminal commands daily, and their machines hold tokens that publish packages, push code and reach cloud accounts.

Fix it without waiting for upstream

A ClickFix infection on a developer laptop becomes everyone's problem when stolen tokens are used to publish bad versions, or when the cleanup shows how far behind your dependencies already are. The fix and rebuild work that follows is the same work as for any vulnerable component.

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

None of these demos show a ClickFix attack. Each is a real Safeguard session, applied here to the cleanup and hardening work above.

The first demo is a CLI session that fixes a lodash CVE. The assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. After a ClickFix scare, you could use the same session to ask it to move a package's publish workflow to trusted publishing, or to pin away from a version you no longer trust, and see every command before it runs.

Click through it at your own pace, or open it full screen.

The second demo is a desktop app session, which is in early access. The CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with an upgrade done and tests passing. The Approve or Deny step is the habit this whole post argues for: no command runs on a developer machine until a person has read it.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session, also in early access: work is sent to a computer running the CLI, and the command is approved on the phone with Allow once, Allow for turn or Deny. During an incident, the engineer on call can approve rebuild and test commands from a phone, or deny one that looks wrong.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• MITRE ATT&CK: T1204.004 User Execution, Malicious Copy and Paste
• Cyber Security Agency of Singapore: Ongoing ClickFix Campaign (AL-2025-068)
• SANS Internet Storm Center: Fake GitHub Site Targeting Developers
• The Hacker News: Google Chrome adds ClickFix warnings to stop users from running malicious commands
• BleepingComputer: Google Chrome adds Gemini powered scam detection, warns users of ClickFix attacks
• 9to5Google: Google says Chrome's Safe Browsing Enhanced Protection mode makes users 10x safer
• MakeUseOf: ClickFix surged 517% in six months, but Chrome can now catch it
• BleepingComputer: Apple adds macOS Terminal warning to block ClickFix attacks
• BleepingComputer: Hackers abuse Google ads, Bing redirects to push Claude ClickFix attacks
• BleepingComputer: New FileFix attack uses cache smuggling to evade security software
• Microsoft Learn: about_Language_Modes
• Microsoft Learn: Use App Control to secure PowerShell
• Microsoft Learn (archived): Remove Run menu from Start Menu
• Anthropic, Claude Code docs: Advanced setup
• npm Docs: Trusted publishing for npm packages

Last reviewed: 22 October 2026. Browser and operating system protections against ClickFix are changing quickly; check the linked vendor pages for current behaviour.