[macOS 26.3.1(a)] "Results from Clipboard" in spotlight keeps being reenabled after reboot

Hey!

This affects me as well on macOS 26.4.1, on MacBook Pro with M5. The following workaround works for me:

Here is a command that simply disables clipboard history in Spotlight just like removing a check from the checkbox in the System Settings app would: `defaults write com.apple.Spotlight PasteboardHistoryEnabled -bool false`.

We want to run it on login, but I found out that there is apparently a race condition: if this command is executed once on login, something re-enables Spotlight clipboard later on (only once though). So instead let's run it every 10 seconds, just in case!

Create a file `~/.local/bin/disable_spotlight_clipboard` with the following contents:

```

#!/bin/bash

set -Eeuo pipefail

while true; do

    defaults write com.apple.Spotlight PasteboardHistoryEnabled -bool false

    sleep 10

done

```

Make it executable: `chmod +x ~/.local/bin/disable_spotlight_clipboard`.

Create file `~/Library/LaunchAgents/com.user.disable-spotlight-clipboard.plist` with the following contents:

```

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

    <key>Label</key>

    <string>com.user.disable-spotlight-clipboard</string>

    <key>ProgramArguments</key>

    <array>

        <string>/Users/YOUR_USERNAME/.local/bin/disable_spotlight_clipboard</string>

    </array>

    <key>RunAtLoad</key>

    <true/>

    <key>KeepAlive</key>

    <true/>

    <key>StandardErrorPath</key>

    <string>/Users/YOUR_USERNAME/Library/Caches/disable-spotlight-clipboard.log</string>

    <key>StandardOutPath</key>

    <string>/Users/YOUR_USERNAME/Library/Caches/disable-spotlight-clipboard.log</string>

</dict>

</plist>

```

Reboot and verify that the Spotlight clipboard functionality remains off, and that our script is running: `ps aux | grep disable_spotlight_clipboard`.

DISCLAIMER: I checked that this works, but since I am coming from Linux, this may not be the idiomatic Mac way to solve this problem.

UPDATE: In the code above, "YOUR_USERNAME" is a placeholder for your username, make sure to replace it with an actual value.

I have two machines that were both exhibiting this issue.

One is an M5 Max MBP running Tahoe 26.5.1.

The other is a brand new M5 Pro MBP running Tahoe 26.6.2.

On the first machine (running 26.5.1), I was able to solve the issue by running this command after disabling clipboard history via Spotlight settings. Make sure to close the settings app before running the command. Then restart to verify the fix:

defaults delete com.apple.spotlight PasteboardHistoryTimeout

It seems the existence of this key was causing the feature to get reenabled on restart.

To be extra sure, I reproduced the issue again by re-enabling the clipboard history and fixed it again with the above command. So it's definitely a reliable fix on that machine with that version of macOS.

However, on the other machine running 26.6.2, this solution doesn't work. I've not yet migrated data to this machine and there are very few 3rd party apps installed (just some very standard stuff like Carbon Copy Cloner).

I see the 26.6.0 release notes mention it "optimizes the Spotlight index in preparation for macOS 27", so there were changes to Spotlight between those releases that could maybe explain the discrepancy. Or there could be some race condition in the mix as another user noted. This does seem like a bug in macOS to me based on the above.

I have updated the file contents a bit to make the workaround more robust.

`disable_spotlight_clipboard` now only performs the setting write if it has the wrong value, which avoids modifying the settings database too often for no reason, and also logs the changes:

```

#!/bin/bash

set -Eeuo pipefail

domain="com.apple.Spotlight"

key="PasteboardHistoryEnabled"

while true; do

    value="$(defaults read "$domain" "$key" 2>/dev/null)"

    if [[ "$value" == "1" || "$value" == "true" || "$value" == "YES" ]]; then

        defaults write "$domain" "$key" -bool false

        logger "/Users/user/.local/bin/disable_spotlight_clipboard: Set $domain $key to \"false\""

    fi

    sleep 10

done

```

`com.user.disable-spotlight-clipboard.plist` now uses more idiomatic path for log files (minor change):

```

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

    <key>Label</key>

    <string>com.user.disable-spotlight-clipboard</string>

    <key>ProgramArguments</key>

    <array>

        <string>/Users/user/.local/bin/disable_spotlight_clipboard</string>

    </array>

    <key>RunAtLoad</key>

    <true/>

    <key>KeepAlive</key>

    <true/>

    <key>StandardErrorPath</key>

    <string>/Users/user/Library/Caches/com.user.disable-spotlight-clipboard.log</string>

    <key>StandardOutPath</key>

    <string>/Users/user/Library/Caches/com.user.disable-spotlight-clipboard.log</string>

</dict>

</plist>

```

This issue is not reproducible on 1 M4 Desktop, 1 M4 Laptop and 1 M2 Desktop each running Tahoe 26.4

This does not mean it is not happening on your machine

To avoid a game of 20 questions   

Download the Application Etrecheck  ( External Link ) directly from the Developer.

This is a Diagnostic Tool that makes no changes to the computer.

It makes a coherent and readable inventory of both the Hardware and Software used on the computer 

The application is free or paid for added features. 

The Report will Not Reveal Any Personal Information. 

Post back the Full Report - Share Report >> Copy , then  paste  >>>> using the Additional Text Icon  <<<<

• OS Version: macOS 26.3.1(a) (Tahoe)

macOS 26.4 is the current release.

Update macOS on Mac - Apple Support

Pepin Hazan wrote:

I agree that a Backblaze breach would expose lots of data, but it would normally not expose data such as credit card numbers, social security numbers, passwords (from non-Apple password managers), and so on if you aren't storing them in plain text on your machine. The clipboard history could inadvertently expose such information, so I don't agree that it's a meaningless distinction. The breach would be worse if such data was exposed.

If you are using the clipboard for things like SS numbers, credit card numbers, passwords, etc. it seems like it would be prudent to clear the clipboard (an option in System Settings that does work) afterwards so that it can no longer be viewed. Browser caches and other caches and tools can also contain these data, this would not be limited to concern about what is in the clipboard. I believe that all these caches in user Libraries are backed up by Backblaze.

It could absolutely be a built-in macOS flaw. A bug can exist in macOS without affecting all users.

I agree it could be a macOS flaw that I don't see on my machine (which is Intel) but might be seen on other models of Macs. But clearing the Clipboard is a reasonable workaround.

I've attached the EtreCheck report from the second machine I mentioned (running 26.6.2). The only notable third party daemon running is Logitech software, which is not installed on the other machine that exhibits this issue. You can see from the report there's very little installed on the system and no issues reported.

Logitech software has caused other issues reported in Apple Discussions. That said, does this issue present to you in Safe Mode? Safe Mode disables most user installed items, that would be interesting to know.

I can't install EtreCheck on the other machine, as it's a work issued laptop.

Etrecheck doesn't actually "install," it just downloads an executable that you can then run.

Pepin Hazan wrote:

• I appreciate your attempt to help, but I feel I should correct some things:

Backblaze does not back up browser caches. It excludes such directories for major browsers because backing them up would waste bandwidth. It also does not back up ~/Application Support/Caches and many other locations of "transient" data for the same reason.

I noticed this on Backblaze's site: "By default, Backblaze backs up the Mac user-level library for each user at /Users/yourusername/Library or ~/Library."

https://www.backblaze.com/computer-backup/docs/supported-backup-data

That would appear to include user caches (which exist for scores of programs, not just for browsers). Perhaps the above documentation is incorrect.

I have already tested the issue in Safe Mode, and it persists.

Etrecheck reports and testing in Safe Mode can identify certain things, but if Terminal commands have been made to directly modify preferences or other items, those can remain in the changed state through Safe Mode and would not be seen in the Etrecheck Report.

A comment about perceived versus real risk. Humans are known for not correctly estimating relative risks. For instance people get scared when taking airplane flights, yet mathematically the much riskier part of that trip is the car drive to the airport, which people tend not to worry about.

So ... the risk of, say, a social security number being retained on the Clipboard History and displayed during screen sharing? I think that can be made to be equal to zero by clearing the clipboard. Or by simply not using the clipboard for such sensitive data.

... the risk of a social security number being retained in a Clipboard History File that is backed up by Backblaze and then exposed when there is a breach at Backblaze? Not to discount your concern, but I copied a unique text string into the Clipboard and then searched through all visible and hidden files on the Mac (Tahoe 26.6.2) for that unique text string (using Find Any File) and no file was found containing that string.

I also wonder if this perceived risk of a Backblaze breach is properly calibrated versus other risks. A social security number must be provided to obtain a cell phone with companies like AT&T, Verizon, etc. Banks and credit unions you use have your social security number and at least some employees of these institutions have access to these things. What about secure storage of personal data with tax software companies, where they store everything on THEIR servers when you choose the option to "encrypt" the tax return. What about security of IRS and state tax data we submit every year and are stored (somewhere) for a long time? Recently some high profile individuals' tax returns were "leaked" to the press.

I am questioning if the Clipboard History is actually placed into a file. Have you ever seen unique Clipboard history contents in a file? Posing a question online to AI (which I don't really trust, but I did it anyway) comes back with a statement that on the Mac the Clipboard History is stored in RAM.

You do have a legitimate issue in that on your Macs at least you have found that a System Setting regarding Spotlight and Clipboard History does not persist or switches back to a different setting. So that could be a bug that should be addressed. Having worked in spacecraft flight software for many years, at our company we had to keep a list of discovered or known bugs (all software has bugs) and prioritize which ones to fix first, given that software engineers were a limited resource and there was limited time before spacecraft launch, and limited ability to correct the software post-launch. Part of that prioritization was a risk & consequence algorithm that measured the severity based on the likelihood of occurrence and the consequence of such occurrence. I am expecting that companies like Microsoft, Apple, Adobe, etc. also do this and that if they know about this bug, it might not rise high on the severity/risk/consequence scale.

You should report bugs to Apple here: Feedback - macOS - Apple

On my 2019 Intel MacBook Pro 16" (a different chip) with Tahoe 26.6.2 my Results from Clipboard toggle is OFF and stays off through reboots, whatnot.

I see the conversation here includes various scripts and terminal commanding that I am not familiar with. I tend to stay away from those things unless I understand the underlying unix elements and implications thoroughly. But my laptop seems to behave normally so there is nothing to fix. Part of me wonders what other terminal commands have been used in the past that might have disrupted some of the users' "Results from Clipboard" setting/toggle.

Also, I don't really see the privacy/security issue here. The only one who could see these searches would be the user who is logged in to your account. If they can access your computer to log in to your account, they can do a lot more than search the clipboard.

I also see that no one has done what Owl-53 suggested, namely posting an Etrecheck report.

There are security issues here. If you use cloud backup like Backblaze or similar, it is potentially including the contents of this clipboard history in a form that could be reconstructed if the service was breached. This data would persist for Backblaze’s archival window (1 year). The location of this history is not documented so can’t be easily excluded from backups. If you use spotlight search while screen sharing or similar you can also inadvertently expose clipboard data. Neither of those issues exist if you limit yourself to the standard clipboard.

The terminal command I mentioned is equivalent to changing the corresponding system preference and was only run after the issue appeared. It’s not the cause of the issue.

I can try to post an EtreCheck report later to satisfy the request, but the two machines exhibiting this issue have literally zero third party software in common after comparing (one is a work machine, the other essentially brand new). It isn’t going to come down to some misbehaving daemon or similar—at least not from a third party developer.

Pepin Hazan wrote:

There are security issues here. If you use cloud backup like Backblaze or similar, it is potentially including the contents of this clipboard history in a form that could be reconstructed if the service was breached.

That is certainly true. But if such a cloud backup service were to be breeched and your backed up data accessed, I think you would have much larger problems than the contents of your clipboard.

If you use spotlight search while screen sharing or similar you can also inadvertently expose clipboard data. Neither of those issues exist if you limit yourself to the standard clipboard.

This also seems pretty obscure to me. You could clear the clipboard first, but doing such a search while screen sharing and not knowing what others might see seems careless to me. Anyone doing screen sharing has to know to take precautions not to expose what they don't want others to see.

This is not a built in macOS flaw because it doesn't happen when I do this, the toggle switch stays where I put it. The anomaly is that something exists on those computers that is switching the toggle switch back.

I can try to post an EtreCheck report later to satisfy the request, but the two machines exhibiting this issue have literally zero third party software in common after comparing (one is a work machine, the other essentially brand new). It isn’t going to come down to some misbehaving daemon or similar—at least not from a third party developer.

Well, there has to be some reason for this happening. It certainly does not happen on my computer on Tahoe 26.6.2.

That is certainly true. But if such a cloud backup service were to be breeched and your backed up data accessed, I think you would have much larger problems than the contents of your clipboard.

I agree that a Backblaze breach would expose lots of data, but it would normally not expose data such as credit card numbers, social security numbers, passwords (from non-Apple password managers), and so on if you aren't storing them in plain text on your machine. The clipboard history could inadvertently expose such information, so I don't agree that it's a meaningless distinction. The breach would be worse if such data was exposed.

This is not a built in macOS flaw because it doesn't happen when I do this, the toggle switch stays where I put it. The anomaly is that something exists on those computers that is switching the toggle switch back.

It could absolutely be a built-in macOS flaw. A bug can exist in macOS without affecting all users.

I've attached the EtreCheck report from the second machine I mentioned (running 26.6.2). The only notable third party daemon running is Logitech software, which is not installed on the other machine that exhibits this issue. You can see from the report there's very little installed on the system and no issues reported. I can't install EtreCheck on the other machine, as it's a work issued laptop.

If you are using the clipboard for things like SS numbers, credit card numbers, passwords, etc. it seems like it would be prudent to clear the clipboard (an option in System Settings that does work) afterwards so that it can no longer be viewed. Browser caches and other caches and tools can also contain these data, this would not be limited to concern about what is in the clipboard. I believe that all these caches in user Libraries are backed up by Backblaze. I agree it could be a macOS flaw that I don't see on my machine (which is Intel) but might be seen on other models of Macs. But clearing the Clipboard is a reasonable workaround.

I appreciate your attempt to help, but I feel I should correct some things:

• Backblaze does not back up browser caches. It excludes such directories for major browsers because backing them up would waste bandwidth. It also does not back up ~/Application Support/Caches and many other locations of "transient" data for the same reason.
• Browser caches do not typically contain passwords entered by the user.
• Backblaze is continuous backup that constantly monitors for changes to the file system. Unless you stop the backup process entirely every time you use the clipboard, it could back up the contents between when you copy something and when you clear it. The "best practice" here would really be excluding Spotlight's clipboard history folders/files from Backblaze, but their location is not officially documented. "~Library/Application Support/Knowledge" appears to be involved, so I can exclude that. But it's hard to say if everything is there without official communication. For the time being, that is what I plan to do.

Logitech software has caused other issues reported in Apple Discussions. That said, does this issue present to you in Safe Mode? Safe Mode disables most user installed items, that would be interesting to know.

I have already tested the issue in Safe Mode, and it persists. The Logitech software was installed weeks before this issue started and is not present on my other machine with the same issue.

Etrecheck doesn't actually "install," it just downloads an executable that you can then run.

I'm aware that Etrecheck doesn't have an installer package (I did after all just install it on my other machine to produce that log). The installation method doesn't make a difference in the case of this work machine. It's a policy matter, not a technical one.

I noticed this on Backblaze's site: "By default, Backblaze backs up the Mac user-level library for each user at /Users/yourusername/Library or ~/Library." https://www.backblaze.com/computer-backup/docs/supported-backup-data That would appear to include user caches (which exist for scores of programs, not just for browsers). Perhaps the above documentation is incorrect.

Backblaze's actual exclusions are much more complex than reflected on that page. I am 100% certain ~/Library/Caches is not backed up. The full list of exclusions is in a file "bzexcluderules_mandatory.xml" that's installed with the program (unsure if you use Backblaze yourself). The Restore tool can also be used to verify it's not backed up.

Etrecheck reports and testing in Safe Mode can identify certain things, but if Terminal commands have been made to directly modify preferences or other items, those can remain in the changed state through Safe Mode and would not be seen in the Etrecheck Report.

To be clear, no Spotlight-related or clipboard-related terminal commands were run before the issue appeared. I would not paste commands into the terminal that I don't understand. The issue was not caused by blindly messing about with Spotlight-related terminal shenanigans. I did not run the more lengthy scripts posted by other users in this thread.

Ultimately, we can agree to disagree on whether this is a "meaningful" risk. I am not trying to imply this is a giant security hole, but I am not looking to be convinced that the issue doesn't matter either.

Not to discount your concern, but I copied a unique text string into the Clipboard and then searched through all visible and hidden files on the Mac (Tahoe 26.6.2) for that unique text string (using Find Any File) and no file was found containing that string. ... I am questioning if the Clipboard History is actually placed into a file. Have you ever seen unique Clipboard history contents in a file? Posing a question online to AI (which I don't really trust, but I did it anyway) comes back with a statement that on the Mac the Clipboard History is stored in RAM.

In this case, the AI is wrong. If Clipboard History is disabled, then the clipboard is only stored in RAM. I'm certain Clipboard History is written to disk, because it persists after restart/shutdown. This does not mean it's stored as a plain text string that would come up in your search. We know for instance that it's integrated into the Spotlight index, which is going to be structured in a way that optimizes search performance. I do not necessarily believe the other user's post is correct about the history being located at ~/Application Support/Knowledge. But it is definitely somewhere--potentially multiple places (e.g. perhaps with strings/metadata in the spotlight index, pointing to the full content elsewhere).

You should report bugs to Apple here: Feedback - macOS - Apple

I indeed submitted a report via Feedback Assistant when the issue first appeared.

I do appreciate the help, and perhaps this issue will disappear entirely when Golden Gate releases.