A warning people learn to dismiss is not a control
Two unrelated items from the last day describe the same failure from opposite ends.
The first is the SANS write-up of the Macfinger ClickFix stealer on macOS. Nothing in that infection bypasses the operating system's protections. The victim pastes a command into Terminal because a web page asked them to, and after that the malware simply asks: access to Documents, Desktop and Downloads, to the photo library, to Apple Music, control of Notes, then the administrator password and the Keychain password. Each dialog is genuine and each one is doing its job. The attack is built on the fact that people approve dialogs, because nearly every dialog they have ever seen was harmless.
The second is CodeQL 2.27.1, most of whose changelog is about alerts that should not have fired: actions pinned through a lockfile still reported as unpinned, LINQ rewrites suggested that would not compile, an anti-forgery check that did not see a globally registered filter. None of this is exciting. All of it is the maintenance that decides whether anyone reads the next alert.

The shared mechanism
A warning is only a control if someone acts on it, and whether they act depends on what the previous hundred warnings turned out to be. Every false positive spends a little of that credibility; spend enough and the rule is still running, the dashboard still counts it, and the organisation has in practice turned it off. The macOS consent system is the same thing at the scale of a whole platform: prompts are so frequent and so usually benign that a sequence of six of them reads as friction rather than as an alarm.
That points to two habits worth having.
First, count dismissals, not just alerts. A code-scanning rule whose findings are mostly closed as "won't fix" or "false positive" is not protecting you; it is training people to click. Either fix the rule, scope it, or remove it - a smaller set of alerts that are always real is worth more than a large set that is sometimes real.
Second, move the decision away from the moment of the prompt. The effective defences against ClickFix are not better dialogs but policies that make the dialog unnecessary: Terminal should not be launching download-and-execute chains on a managed laptop, new LaunchAgents named after Apple services should raise an alert somewhere nobody has to approve anything, and staff should know that no website ever needs a Terminal command. In code scanning the equivalent is enforcing pinning in CI, so the alert is a backstop rather than the only line.
Both items end in the same place. A control that relies on a person noticing something is only as good as the last time that person was right to ignore it.