macOS has no permission gate for the pasteboard
Your Mac asks before an app uses the camera. It asks for the microphone, for screen recording, for your Documents folder, for your contacts. The pasteboard is not on that list. Any process in your user session can call the pasteboard API, read the current contents, and you will never know.
The design is old, and that explains a lot. ctrl.blog's write-up dates the clipboard to 1973 and documents how differently each operating system guards it. It was built to move a few characters between two programs on one trusted machine. Passwords, bearer tokens and card numbers arrived later.
Apple states the risk on its own support page. The macOS 26 Spotlight clipboard history documentation says: "Sensitive information may appear on the Clipboard."
The iPhone made the same reads visible
On iOS the reads were constant and nobody could see them. In 2020, security researchers Talal Haj Bakry and Tommy Mysk found 53 popular apps reading the pasteboard with no reason to do it. Apple's answer in iOS 14 was a banner. When an app pastes from another app, you now see a notification saying so.
Sophos covered the fallout, including TikTok among the apps the banner exposed. Behaviour changed quickly once the reads were attributable to a name on the screen.
macOS never got that banner. Same capability, same freedom, no notification.
A clipboard manager changes the shape of the problem rather than the permissions. The read is still unrestricted. What changes is duration: one item held for four seconds becomes a searchable record that stays until something deletes it.
That cost applies to every history app, mine included. The controls that matter are an exclusion list, a retention limit and a clear button, and you should check all three before you trust any of them.
Firefox treats a copied password as a special case
Browsers moved on this before operating systems did. Firefox 94 and ESR 91.3 stopped handing password-field and private-browsing copies to OS clipboard history and cloud sync. Mozilla wrote it up, and it is tracked as CVE-2021-38505.
The scope is narrow, so be precise about it. The copy still reaches your clipboard, and ⌘V still works. What stops is the copy being handed to anything that keeps a record of it. Older Firefox builds passed those copies straight through.
Chrome and Safari do not publish an equivalent behaviour. I would assume a password copied in either one is recordable.
Your password manager does the other half
1Password's writing on the clipboard problem sets out its reasoning plainly: prefer AutoFill, and clear the clipboard 90 seconds after a copy. Bitwarden ships the same setting. Open yours and confirm it is on, because it is the only control here that limits how long a secret sits in the slot.
AutoFill beats every setting on this page. A password that never touches the clipboard cannot be read out of it.
Where the alarm is misplaced
An app reading your clipboard already runs as you. It can open your Documents folder, read your Downloads, and see your Desktop. The pasteboard is one item on a longer list of things a process in your session can touch. Unrestricted clipboard access is a bad default, and it is not a privilege escalation.
Most reads are boring. Apps check the pasteboard to offer a paste suggestion, to spot a copied URL, to recognise a tracking number. The iOS 14 finding was damning because those 53 apps had no use for the data, not because reading is automatically hostile.
The reads worth worrying about come from malware. Code running as your user can watch the pasteboard and swap what it finds. In June 2026, The Hacker News reported a Rust clipper campaign against Windows and macOS, with a Check Point sample carrying more than 15,500 attacker wallet addresses to substitute. No clipboard setting stops that. Not running the malware does.
How I built mine
Klipto keeps everything in a local database inside its own container on the Mac. No account, no sign-in, no sync, nothing uploaded. It touches the network for one purpose, checking for updates, and that check is a toggle. I ran a network monitor beside it for an hour and saw zero outgoing traffic, which I treat as the baseline rather than a feature.
Two honest limits. The password-manager exclusion lives in Settings, then General, and it is off until you switch it on. And a password copied out of a web page or a text file still gets recorded, because nothing in the copy marks it as sensitive. Type detection flags likely passwords by shape, which is a guess.
If you want free local history and nothing else, Maccy stores locally too and is a good answer.