Stop macOS Sequoia install app automatic downloads?

Curious what others say to stop the download. 

But what about creating a smart group for those that have the Install macOS Sequoia.app, then running a script to remove/delete it?

Interesting... We install (in my opinion) too many agents on our Macs. If it was one of them causing this, I wonder why it doesn't do this on every Mac. I have a policy that finds and deletes the install app. I see that it has been successful doing that.

We have quite a few ourselves, and are actually evaluating for overlaps and consolidations in 2025 thank god.

For us its a EPM tool that loves to get in the way. You need to write new policies for it's allow rules as Apple updates things, and different devices are in different enforcement levels for one reason or another leading to tons of variables. 

The first way is to not grant admin rights to your users. If you're not an admin, you can't install a new major release. As second, you can configure Restricted Software to prevent the execution of Install macOS Sequoia.app. And last but not least configure the Restrictions part of a Configuration Profile. Under the tab Functionality you can find "Defer updates for..." so it would not be shown as available update.

Right now, all of our Macs not yet upgraded to Sequoia currently display a 15GB upgrade size, meaning that the Mac will be downloading the full installer. A moment ago, I created a new Mac VM running Sonoma and did not enroll it into my Jamf Pro server. It has none of our software installed. Software Update is showing at 7.5GB download for Sequoia. So, I am going to enroll this VM in Jamf Pro and exclude it from all the agent install policies. I will check Software Update after enrollment, and keep checking it after I manually install one of our agents. Maybe this will pin down which agent is responsible for interfering with the upgrade. We have seen some random failures to run minor updates where macOS displays an error similar to "update settings have changed". We were never able to pinpoint what caused it and the updates would eventually work.

As it turns out, your idea of the full installer app downloading as a "fall back" was correct. We defer most updates for a set period of time to give us time to test the new version and make sure nothing will break before we allow everyone to update. I noticed that the profile we use to defer major macOS upgrades had what looked like a conflicting setting in it. It defers the major upgrades for the specified time, but it seemed to be causing Software Update to download the full installer. Removing this conflicting setting has resulted in the smaller delta upgrade being presented in Software Update. Thank you for giving me the idea of this being a fall back behavior because something is breaking the workflow. Because of this issue, I was having to run a policy to temporarily elevate non-admin users to admin so that they could get the upgrade to Sequoia done. A follow up policy demotes them back to standard. The process is working perfectly, but I would prefer not to have to use it.

Im glad I was of some help. 

Ironically we are actually having issues with this right now. Our EPM tool which has a local account with a secure token is screwing with the volume ownership workflow of the OS updates triggering macOS to download the full OS installer. Im trying to keep from giving people admin access as a work around as my security team (or rather in the end it will be me) figures out the configuration issue. The fun never ends :).

I don't envy you on that. I hate CyberARK EPM. Absolutely HATE IT! Or at least I hate the way it's setup. I noticed last year, that a user can run "sudo jamf removeFramework" in Terminal. We were told by CyberArk that we can't block specific commands. Really? That makes this software useless. Just allow users to be admin since CyberArk lets them remove the Jamf framework and without prompting for a password.

There are problems with your approach. If Software Update ends up downloading the full installer, and it launches, it will immediately get quit by Restricted Software. Therefore, even an admin user cannot do the install. I don't want to block installs. I want my users to be able to upgrade to macOS Sequoia from a previous macOS. If the upgrade is handled entirely through Software Update without the install app, a non-admin user can perform the major upgrade as long as they are a volume owner on the Mac, which all of my users are. I don't use the built-in deferral payload because we often need to be a lot more granular with the number of days instead of using the prebuilt options Jamf provides us. I use a JSON that allows me to set the destired deferral days. I usually defer minor updates for 21 days, enough time for my pilot group to tell me if they have issues. If you read my comment left yesterday, you will see that I discovered that I had what was likely a conflicting setting in my deferral profile that caused macOS to download the full installer instead of the smaller upgrade that would normally appear for a Mac running an older macOS. Once I removed that conflicting setting, Software Update now shows the much smaller upgrade, around 7.5GB instead of the full 15GB installer. I had some of my users run the install. These were non-admin users. They were able to get upgraded to macOS Sequoia without issues.  Install ran entirely through Software Update, and the installer app never downloaded or launched. I block the installer app only for a short time when we don't wany anyone downloading it or copying it over to their company owned Mac in an attempt to get around our upgrade restrictions. I also block the beta installers.

Thankfully I dont manage EPM, we have very high wall dividing Infrastructure (people who manage the environment) from Security (people who make stupid policies). Though our EPM folks lost their Mac expert, and have been coming to me a lot frequently...

EPM should be able to block that command, sounds like someone is not good at writing policies. I get a blanket policy to allow sudo Jamf to allow recon, but I would assume they can write a specific block policy for removeFramework. Now you have me wanted to test this lol.