MainspringGuides › Settings vs Terminal
macOS Guide

System Settings vs Terminal: Which Should You Use?

Updated August 2026 · 3 min read

System Settings and defaults write are two doors into the same room. Mostly. Understanding where they overlap, where they do not, and why they occasionally show you different answers explains most of the confusion around hidden Mac settings.

They write to the same place

Both write preference values into domains managed by cfprefsd, the preferences daemon. Tick a box in System Settings, then read the value in Terminal, and you will see what changed:

# before the change
defaults read com.apple.dock autohide

# tick "Automatically hide and show the Dock", then
defaults read com.apple.dock autohide

This is also the best way to discover an undocumented key: snapshot a domain, make the change in the app, snapshot again, and diff the two.

defaults read com.apple.finder > /tmp/before.txt
# make the change in Finder settings
defaults read com.apple.finder > /tmp/after.txt
diff /tmp/before.txt /tmp/after.txt

What only Terminal reaches

Plenty of settings have a working key and no interface. The Dock's auto-hide delay, the screenshot shadow, key repeat below the slider's minimum, menu bar item spacing, the Finder window title path. Apple has no obligation to expose everything, and some of these were internal options that were never meant to be public. They work; they are just undocumented.

What only System Settings reaches

The reverse is also true, and it catches people out. Anything protected by TCC — the permissions system behind Privacy & Security — cannot be granted from the command line. You cannot script your way into Full Disk Access, Screen Recording or Accessibility permissions, and that is a deliberate security boundary rather than an oversight. Same for FileVault keys, Apple Account sign-in and anything requiring a hardware authorisation.

Why they sometimes disagree

Three real reasons, in order of how often they bite:

  1. Caching. cfprefsd holds preferences in memory. Writing a value while the owning app is running means the app may overwrite you when it next saves. Quit the app first.
  2. The host scope. Some values are per-machine rather than per-user and need the -currentHost flag. Menu bar spacing is the classic case: without the flag the write succeeds and nothing happens.
  3. Sandboxing. App Store apps store preferences inside their container, so the domain you want may live in ~/Library/Containers/<bundle id>/Data/Library/Preferences rather than ~/Library/Preferences.

When to use which

Where the values actually live

Preferences are stored as property list files, and knowing where they are makes both routes less mysterious:

# your own preferences
ls ~/Library/Preferences

# per-machine preferences (the -currentHost ones)
ls ~/Library/Preferences/ByHost

# system-wide
ls /Library/Preferences

You should not edit these files directly while macOS is running, because cfprefsd caches them and will overwrite your edit. Read them if you are curious, write them through defaults or the interface. If you ever do need to force a reload after copying a file in from elsewhere, killall cfprefsd is the command, and it is safe.

The rule that prevents most problems

Whichever route you take, know how to reverse it. From System Settings that is usually obvious. From Terminal it means defaults delete rather than writing the opposite value, because macOS distinguishes between a preference set to false and one that was never set at all:

# removes your change entirely
defaults delete com.apple.dock no-bouncing && killall Dock

Keep a list of what you have changed by hand. Undocumented keys can be retired by an OS update, and when something behaves oddly after an upgrade, your own list is the first and best place to look.

Both doors, one interface

Mainspring covers the Terminal-only settings with the clarity of a settings screen: labelled toggles, plain descriptions, and an undo that removes the key rather than overwriting it.

Try Mainspring free →

Signed & notarized by Apple · 1-day free trial · $29 once