dotfiles: `defaults write` doesn't work on Safari on Mojave

This may be caused by permissions. On Mojave Mail is blocked from apps by default. In Bash you will see this by default:

 $ cd ~/Library/Containers/com.apple.mail
 $ ls
ls: cannot open directory '.': Operation not permitted

And defaults read -app Mail will only show these options:

{
    BundleCompatibilityVersion = 3;
    EnableBundles = 1;
    NSNavLastRootDirectory = "...";
    NSNavPanelExpandedSizeForOpenMode = "{720, 448}";
}

You need to add Bash (and maybe others like iTerm, Terminal, etc) to the Full Disk Access list. When you click +, use <kbd>⇧</kbd> + <kbd>⌘</kbd> + <kbd>G</kbd> to open the Go to folder dialog so you can pick items like Bash. You need to pick the exact one you are using. I am using MacPorts so everything is in /opt/local/bin for me.

Once you’ve done this, start a new shell (already running shells will not work) and type defaults read -app Mail and it will show all settings. It does not work for me in tmux (not sure why yet). Run this command in a bare shell.

 $ defaults read -app Mail | fgrep DisableSendAnimations
    DisableSendAnimations = 1;

For Safari you will have to change the command to use the property list file without the .plist extension with defaults:

defaults write ~/Library/Containers/com.apple.Safari/Data/Library/Preferences/com.apple.Safari AutoOpenSafeDownloads -bool true

There are other property lists as well in this path.

 $ la *.plist
-rw------- 1 tatsh staff    42 2018-05-13 07:44:40 com.apple.Safari.Extensions.plist
-rw------- 1 tatsh staff   103 2018-07-10 19:37:31 com.apple.Safari.SafeBrowsing.plist
-rw------- 1 tatsh staff    42 2018-05-11 12:03:35 com.apple.Safari.Support.plist
-rw------- 1 tatsh staff 11086 2018-10-11 19:26:37 com.apple.Safari.plist
-rw------- 1 tatsh staff   130 2018-09-17 21:45:30 com.apple.SafariBookmarksSyncAgent.plist
lrwxr-xr-x 1 tatsh staff    51 2018-07-12 04:00:53 com.apple.security.plist -> ../../../../../Preferences/com.apple.security.plist
lrwxr-xr-x 1 tatsh staff    58 2018-07-12 04:00:53 com.apple.security_common.plist -> ../../../../../Preferences/com.apple.security_common.plist

I presume almost all apps including Apple’s are going in this direction, as this is what has been done on iOS especially since 11.

Apple always leaves hints regarding migrations:

 $ plutil -p com.apple.Safari.plist | fgrep -i migr
  "cloudBookmarksMigrationEligibilityDataInvalidated" => 0
  "cloudKitBookmarksMigrationRampState" => {
      "gmMigrationPercent" => 1000
      "internalMigrationPercent" => 1000
      "seedMigrationPercent" => 1000
  "DidAttemptToMigrateExtensionsPlistFromLegacyKeychain" => 1
  "DidMigrateDisabledPlugInsInfoToAllPlugInsInfo" => 1
  "DidMigrateExtensionSettingsToExtensionsDomain" => 1
  "DidMigrateNewBookmarkSheetToReadingListDefault" => 1
  "DidMigrateResourcesToSandbox" => 1
  "DidMigrateStartPageDefaultSidebarVisibility" => 1
  "DidMigrateTabsToLinksForReaderKey" => 1
  "DidMigrateToCoreSpotlightBasedHistorySearch" => 1
  "DidMigrateToMoreRestrictiveFileURLPolicy" => 1
  "DidMigrateWebKit1Preferences" => 1
  "MigratedIncludeDebugMenu" => 1
  "SearchProviderIdentifierMigratedToSystemPreference" => 1

using the Preferences app to enable Terminal, bash, etc somewhat defeats the automate-ability of a bootstrapping script to automate preferences. Is there a way to automate this part while maintaining SIP enabled?

Makes sure to give Terminal Full Access (I recommend you do this temporarily). Then commands like “defaults write com.apple.mail DisableInlineAttachmentViewing -boolean yes” may work

To work around this a bit more, is anyone aware of a scriptable way to put an application into the “Full Disk Access” list? I’ve seen other applications add themselves into Settings -> Security & Privacy -> Privacy -> Accessibility before. Of course they are by default unchecked, but the user gets prompted to unlock and enable them, which is better than nothing. Would love to find a way to script that before running my dotfiles.

Right, not all apps work with the -app invocation. (And it has always been thus, it’s not a Mojave regression.) If memory serves, only applications that are located in either /Applications or ~/Applications—or at least are symlinked into one of those two—will work in this way. I’m unsure whether all apps that live or symlinkedly live there will work with -app.

I don’t know what to say about the brewed bash, but it might be relevant that what’s in /usr/local/bin is a symlink to bash and not bash itself. Perhaps using /usr/local/opt/bash/bin/bash will work, because though elements of that path are symlinks, the endpoint isn’t.

I used to use -app only when not using it would fail (i.e., containerized on pre-Mojave), but I think I’m now going to never use -app (and where necessary use the full path through the container), at least for scripting. The point of scripting these is to run them on a fresh user (maybe even without being logged into the GUI), which conflicts with the rigamarole of manually granting Full Disk Access.

It should be easy to create a wrapper script that will automatically prepend the container-y path for any domain that is antecedently known to live in a container.