MainspringGuides › Command not working
macOS Guide

defaults write Not Working on Mac? Six Reasons Why

Updated August 2026 · 3 min read

You pasted a command, the terminal returned nothing, and nothing changed. That silence is normal: defaults write succeeds quietly whether or not the key means anything. Here are the six reasons a command does nothing, in the order worth checking.

1. You did not restart the thing that reads it

The most common cause by a distance. Preferences are read when a process starts. Changing them does not notify anyone.

# after Finder settings
killall Finder

# after Dock settings
killall Dock

# after screenshot or menu bar settings
killall SystemUIServer

Anything in NSGlobalDomain applies to apps as they launch, so quit and reopen the app. Some settings — key repeat, menu bar spacing, several window behaviours — need a full logout and login. If a guide says "log out and back in", that is not padding.

2. The app was running and overwrote you

cfprefsd caches preferences in memory. If the owning app is running while you write, it may save its cached copy over yours moments later. Quit the app first, then write, then reopen it. This is why the same command works for one person and not another.

# verify the value actually landed
defaults read com.apple.finder AppleShowAllFiles

If reading it back shows your value but the behaviour has not changed, the problem is number one. If reading it back shows the old value, it is this one.

3. It needs the -currentHost flag

Some preferences are stored per machine rather than per user. Menu bar item spacing is the well-known example. Without the flag the command succeeds and has no effect whatsoever:

# wrong — writes to the wrong scope
defaults write -globalDomain NSStatusItemSpacing -int 8

# right
defaults -currentHost write -globalDomain NSStatusItemSpacing -int 8

4. The key no longer exists

Undocumented keys are undocumented precisely because Apple never promised to keep them. Every macOS release retires some. A command from a 2016 blog post may target something that has not existed for five years, and defaults write will happily create the key anyway and report nothing.

# if this errors before you write, the key is not currently in use
defaults read com.apple.dock some-key

There is no list of retired keys. If a command is old and does nothing after you have ruled out the causes above, that is usually the answer.

5. Wrong domain, or a sandboxed app

App Store apps store preferences inside their container, not in the usual place:

# list every domain that exists on this Mac
defaults domains | tr ',' '\n' | sort

# sandboxed apps keep theirs here
ls ~/Library/Containers/<bundle-id>/Data/Library/Preferences

Also check the spelling. Domains and keys are case sensitive, and NSGlobalDomain, -globalDomain and -g all mean the same thing while globaldomain means nothing.

6. The value type is wrong

Writing a string where macOS expects a boolean stores something the system will not read:

# wrong: writes the text "true"
defaults write com.apple.dock autohide true

# right
defaults write com.apple.dock autohide -bool true

# check what type was actually stored
defaults read-type com.apple.dock autohide

read-type is the underused command here. It tells you whether a value is a boolean, integer, float or string, and comparing yours against a key that works is the quickest way to spot a type mismatch.

A checklist you can run in thirty seconds

  1. Read the value back: defaults read <domain> <key>. Did it land?
  2. If it landed but nothing changed, restart the service or log out.
  3. If it did not land, quit the owning app and try again.
  4. Check the type with defaults read-type against a key you know works.
  5. Try the -currentHost variant.
  6. Confirm the domain exists in defaults domains.

If all six pass and the behaviour still has not changed, the key is almost certainly retired. That is not a failure on your part — it is the cost of using undocumented settings, and it is exactly why keeping a list of what you have applied is worth the two minutes.

If none of that helps

Check whether the setting is managed. On a work Mac, a configuration profile can enforce a value and re-apply it whenever it changes. System Settings → General → Device Management will show a profile if one is installed, and nothing you write locally will survive it.

Skip the debugging

Mainspring applies each setting, restarts whatever needs restarting, and tells you when a change needs a logout. If a setting does not apply, it says so rather than failing silently.

Try Mainspring free →

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