syspolicyd is producing about 2-3TB of read on my SSD every 24 hours (since I leave my device on 24*7). This behavior began after the macOS 10.15.4 update, and has produced about 150TB read. Killing the process, restarting the computer does not help with the case. I am wondering what is this process doing to read data repeatedly, if anyone else has the same problem, and what is a potential solution. Thanks.

Device: Macbook Pro 16 (2019), macOS 10.15.4
Update: problem persists with 10.15.5; problem persists after disabling SIP


Same Macbook Pro 16 macOS 10.15.4 here.

That process verifies 3rd party software. When you open certain apps that process reads (and a lot, if the app is big). It happens to me for example when I open Photoshop 2020, it reads about 1GB.

You say you never turn it off? How much have your laptop been running? If you never power off your computer that read usage stats are not going to be wiped, so they will just keep growing, hence the huge number. If you poweroff so it starts from zero, how much syspolicyd reads in a 24h timespan?

| improve this answer | |
  • That's an idea that could work, if you launch Activity Monitor as root, sudo /System/Applications/Utilities/Activity\ Monitor.app/Contents/MacOS/Activity\ Monitor you can double click on the syspolicyd process and examine which file descriptors it currently has open. (you could also use lsof but I like GUIs :p) Maybe you'll see something that gives you a hint. – kumowoon1025 May 30 at 12:25
  • As I've stated in the description, the process accumulates about 3TB read everyday, regardless of my restarts or kill of the process. This behavior has not happened before 10.15.4, since I can verify with my total SSD read/write status. – user350670 May 31 at 6:17

spctl is the tool to manipulate system policy and/or control syspolicyd.

Try disabling SIP, enabling the root user, and running spctl --master-disable.

It should get rid of the issue, if it doesn't, then something very weird is happening.

But this isn't a fix, it's kind of like replacing a fuse with a jumper wire. So what I think you should do is nuke the security policy database: spctl --reset-default, then reenable it after a reboot: spctl --master-enable.

All these commands need to be done as root, or with sudo

Without knowing what caused the issue in the first place though, I daresay it is likely it is likely to return. It might be some malformed rule was added to your policy db and nuking it fixes the problem, but I sort of doubt that. At least by doing this, hopefully you can diagnose the issue by keeping an eye on when the problem returns (probably after you authorize an application to run - you will need to authorize every single 3rd party non-MAS app to run after the reset)

| improve this answer | |
  • Thanks, I will wait a day to see if it takes effect – user350670 May 31 at 6:18
  • Unfortunately, the process produced ~100G read in an hour even after completely disabling SIP and killed the process. I think there is really "something very weird happening" – user350670 May 31 at 7:31

You must log in to answer this question.