macOS softwareupdate: Disabling Updates, Fetching Installers

Two readers have left the same kind of comment on this post: a command from the documentation, typed correctly, that the Terminal simply refuses. In both cases the command was fine and the article was wrong — it described a version of softwareupdate that no longer exists on the machine the reader was using.

Both are worth walking through properly, because between them they cover the two things people actually come to this command for: stopping macOS from updating itself, and pulling down a full installer.

–ignore is gone, and it isn’t coming back

In May 2026 a reader named Phil asked how to stop update notifications and downloads entirely. He had found the --ignore argument referenced somewhere and tried the obvious thing:

sudo softwareupdate --ignore '*'

Terminal told him ignore was an “unrecognized option”. That error is accurate and it is not a syntax problem — the quoting, the wildcard and the sudo are all fine. The flag has been removed from the tool.

On macOS 26 Tahoe the response is identical to what you get from an option that was never real:

$ softwareupdate --ignore '*'
softwareupdate: unrecognized option `--ignore'
usage: softwareupdate <cmd> [<args> ...]

$ softwareupdate --definitely-not-an-option
softwareupdate: unrecognized option `--definitely-not-an-option'
usage: softwareupdate <cmd> [<args> ...]

Same message, same parser, no special handling. As far as current softwareupdate is concerned, --ignore is a string it has never heard of. It appears in neither man softwareupdate nor softwareupdate --help.

This happened in two documented steps. Apple first announced the deprecation around macOS 10.15.5, in a note that also removed the ability to hide major upgrades: “Ignoring software updates is deprecated. The ability to ignore individual updates will be removed in a future release.” Then an Apple staff reply on the Apple Developer Forums confirmed where it landed:

In macOS Big Sur --ignore has been completely removed. For macOS Catalina, if the Mac is enrolled in DEP you will be able to update to Big Sur using the --ignore flag for all updates, otherwise it’ll only work for non-major OS updates.

So the guides still recommending --ignore are not wrong about the past. They are describing macOS Catalina and earlier, and every Mac on Big Sur or later gets Phil’s error.

What to use instead

The replacement is not another softwareupdate flag — it is writing the preferences directly. These turn off each automatic behaviour independently:

# Disable automatic update check
sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate AutomaticCheckEnabled -bool false

# Disable background download
sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate AutomaticDownload -bool false

# Disable macOS upgrade installation
sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate AutomaticallyInstallMacOSUpdates -bool false

# Disable critical/security update installation
sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate CriticalUpdateInstall -bool false

# Disable App Store auto-updates
sudo defaults write /Library/Preferences/com.apple.commerce AutoUpdate -bool false

To check the settings took effect, read the whole domain back:

defaults read /Library/Preferences/com.apple.SoftwareUpdate

Read the whole domain rather than one key, because of a wrinkle that makes these commands look broken before they have run. On a Mac where nothing has ever written the setting, asking for the key by name doesn’t return “true” — it returns nothing at all:

$ defaults read /Library/Preferences/com.apple.SoftwareUpdate AutomaticCheckEnabled
The domain/default pair of (/Library/Preferences/com.apple.SoftwareUpdate,
AutomaticCheckEnabled) does not exist

The key is absent until something creates it, and automatic checking is on by default in its absence. So “does not exist” before you write is normal rather than a sign the command failed — and it is defaults write that brings the key into being. Checking a key that isn’t there yet is the most common way to conclude, wrongly, that this approach doesn’t work.

There is also a second opinion available, from the flag --help declines to mention:

$ softwareupdate --schedule
Automatic checking for updates is turned on

The man page describes --schedule as returning “the per-machine automatic (background) check preference” — the same automatic-check behaviour the first defaults write above targets. It reports the effective state in a sentence, which makes it a quick sanity check after the writes: if it still says checking is turned on, something has not taken. It is worth knowing this flag exists at all, and as the table further down shows, softwareupdate --help will never tell you it does.

Two things to know about this approach. It is aimed at the machine-level domain in /Library/Preferences, so it needs sudo and applies to the whole Mac rather than one user. And it is a preference, not a lock — the switches in System Settings write the same keys, so anyone with admin rights can turn them back on. That is the honest limit of the defaults route: it stops the Mac acting on its own, not a person acting deliberately.

If you need something a user cannot reverse, the preference domain is the wrong layer. That is what configuration profiles and MDM are for — the Restrictions payload can defer updates on supervised or MDM-enrolled Macs, which is the path Apple opened as it was closing --ignore.

Fetching a full installer, and why version numbers fail

In January 2026 a reader signing as DTE reported the other failure. On High Sierra, this returned an error and a syntax list that offered nothing capable of downloading an installer:

softwareupdate --fetch-full-installer --full-installer-version 10.13.6

The cause is the same shape as Phil’s, running the other direction in time. Apple added --fetch-full-installer and --full-installer-version to softwareupdate starting with macOS Catalina (10.15). High Sierra shipped a version of the tool that predates them, so it does not recognise the flags — no upgrade path, no patch, nothing to configure. The flags are absent from that binary.

Which produces an awkward result worth stating plainly: you cannot use this command on High Sierra to download High Sierra. The tool that fetches installers arrived two releases after the installer being asked for.

And 10.13.6 isn’t on the list anyway

There is a second obstacle behind the first one, which is easy to miss because the version error arrives first. Even on a Mac new enough to have the flags, --full-installer-version can only fetch what Apple currently publishes, and that list is much shorter than people expect:

softwareupdate --list-full-installers

As of July 2026 that catalog returns Tahoe 26.x and Sequoia 15.x builds and stops there. No High Sierra, no Mojave, no Catalina. So even borrowing a modern Mac would not have got DTE 10.13.6 — the version was never going to appear regardless of which machine ran the command. Run --list-full-installers before --fetch-full-installer and you find that out in one step instead of two.

For an installer that old, the realistic routes are Apple’s own download links, documented on Apple Support, or a utility like Mist, which lists older macOS installers and downloads them for you.

–clear-catalog no longer does anything

While checking the above, one more piece of advice fell over — including advice this article used to give. An older version of this page suggested sudo softwareupdate --clear-catalog to force a refresh when updates fail to appear. It doesn’t refresh anything:

$ softwareupdate --clear-catalog
Catalog management is no longer supported.

The option still parses — it is not rejected the way --ignore is — but it prints that line and exits without touching anything. It is absent from both the man page and --help. It survives as a stub that tells you it has retired, which is a friendlier failure than an error but a more misleading one, since a script checking exit status would call it a success.

If updates aren’t appearing, softwareupdate -l without --no-scan forces a fresh scan, and --background --force triggers a check regardless of the “Automatically check” preference.

The man page and –help disagree

The pattern behind all three problems is that there is no single place that tells you what this command can currently do. The two obvious sources contradict each other on macOS 26 Tahoe.

Option	In man	In --help
--schedule	Documented	Not listed
--history	Not mentioned	Listed
--no-scan, --product-types	Not mentioned	Listed
--dump-state, --evaluate-products	Not mentioned	Listed
--clear-catalog	Not mentioned	Not listed
--ignore	Not mentioned	Not listed

Reading only the man page, you would never learn that --history or --no-scan exist. Reading only --help, you would never learn about --schedule. And --clear-catalog is in neither while still responding — which is exactly how it stayed in circulation, and in this article, long after it stopped working. Checking both, and preferring what the binary actually answers, is the only reliable method here.

The flags that do work

With the dead ends cleared out, the working surface is small:

# See what's available (the only command that doesn't need admin auth)
softwareupdate --list

# Download without installing
sudo softwareupdate --download --all

# Install everything recommended, restarting if needed
sudo softwareupdate --install --recommended --restart

# Install one specific item, named exactly as --list prints it
sudo softwareupdate --install "macOS Tahoe 26.5.2-25F84"

# Only macOS, or only Safari
sudo softwareupdate --install --os-only
sudo softwareupdate --install --safari-only

A few points that the flag list doesn’t make obvious:

• --list is the one command that runs without admin authentication. Everything else prompts.
• -r (recommended) and -a (all) are not the same. Recommended items are prefixed with * in --list output, non-recommended with -. The man page notes non-recommended updates are uncommon.
• --restart tries a graceful restart if a user is logged in, and forces a reboot if not. Add --force if you always want the forced path.
• --user and --stdinpass are Apple silicon only — installs there need an owner’s credentials, which is what breaks otherwise-fine deployment scripts carried over from Intel Macs.

The through-line in all three reader reports is the same: softwareupdate has been narrowed, deliberately, over several releases. Update policy moved from flags anyone could type into MDM and configuration profiles, and installer fetching only ever existed for versions Apple still ships. When a command from a guide returns “unrecognized option”, the useful first move is to check --help on the machine in front of you rather than a different Mac’s documentation — the tool is usually telling the truth.