yabai is a window management utility for macOS.

Since macOS does not offer a suitable API to control the native window manager, yabai resorts to injecting a scripting addition into Dock.app for controlling windows. Dock.app is located somewhere in /System which is inaccessible thanks to by SIP.

For yabai to work to it's full potential, the user must partially disable SIP with a command like csrutil disable --with kext --with dtrace --with nvram --with basesystem (Big Sur) or csrutil enable --without debug --without fs (Mojave or Catalina).

This leads me to my question which is, what are the potential consequences of permanently disabling fs and debug?


On a traditional UNIX system—including many major platforms still in use today, such as Debian—any user or process with "root" privileges is considered to have absolute control over a machine. There is basically nothing the OS will not allow a root user to do, whether it's rewriting system files, adding code to other processes, adding code to the kernel, you name it. If you've ever been told not to run programs as root unless absolutely necessary, this is why.

macOS, being itself a UNIX operating system, also behaved this way for many years. As recently as OS X 10.10 Yosemite, once you gave an app your root/administrator password, it was free to do anything it wanted, and macOS would not stand in its way.

All of this changed with the release of macOS El Capitan in 2015. For the first time on the Mac, Apple decided to define a set of actions which they believed no user or program—even one with root privileges—should ever be able to perform! Among these restrictions included installing kernel extensions from unidentified developers (the "kext" protection), injecting code into projected processes, such as apps made by Apple (the "debug" protection), and writing to certain protected system directories (the "fs" protection).

Apple called this new set of restrictions "System Integrity Protection", or SIP for short, and they also made it possible for advanced users to disable, by running a Terminal command from within recovery mode. Disabling SIP reverts your computer to the traditional UNIX behavior of letting root do whatever the heck it wants. Apple also made it possible to individually disable certain restrictions—for instance, running csrutil disable && csrutil enable --without debug will allow injecting code into protected processes, but still leave SIP's other protections in tact.

Suffice to say, disabling SIP grants you a great deal of power over the way your Mac operates. I've recently been learning how to swizzle methods in Objective C; when SIP is off, you can use this to replace code in existing apps, which is really quite fun. When an app does something I don't like—whether it's Zoom making all its windows rudely float on top, or the Dictionary app not respecting my Mac's proxy settings—I can go ahead and change it.

The danger, however, is that if I can inject my own code into any other app, other software potentially could too! You don't need to be particularly creative to imagine the mischief an evil app could cause if it could modify every other app on your machine. For example, an app could inject its own advertisements into Safari, or tell Microsoft Word to send all of its documents to a server in North Korea.

On the other hand, evil apps with root permissions can wreck plenty of havoc without disabling SIP! They won't have any trouble installing bitcoin miners, reading all of your browsing history, and holding for ransom a great many (although not all!) of the files on your hard drive. In fact, a lot of these attacks don't even require root to work. Installing apps is just inherently somewhat dangerous—not unlike inviting someone into your house—unless they come from the Mac App Store, where they're guaranteed to be sandboxed.

I'm only aware of one real-world issue caused by disabling SIP, although it was pretty bad! A couple of years ago, there was a bug in Google Chrome's updater (which sometimes requests root permissions... ugh...) which caused it to overwrite a number of core system files, rendering Macs unbootable. On Macs with SIP enabled, Chrome was prevented from deleting these files, and Chrome carried on its merry way. Presumably, Google never tested Chrome on a Mac without SIP, and so did not discover the problem prior to release. In Google's defense, they did fix the issue quickly, and I'd imagine Chrome now gets tested on Macs without SIP. (But suffice to say, uh, this is why I don't like Google Chrome.)

You should also be aware that on Apple Silicon Macs, Apple does not allow iOS apps to run while SIP is turned off, presumably because developers expect iOS software to only be usable in a locked-down environment. (Those developers are also wrong, because Jailbreaks exist.)

Given all of the above, my general recommendation is as follows:

  • If you don't have a reason to turn off SIP, leave it on. It won't do any harm.

  • If you have a reason to turn off SIP, go ahead, and don't let it keep you up at night. You need to be a bit more careful about which apps you run as root. You need to do that anyway.

Other people can and will fall elsewhere on that spectrum. Hopefully you now have enough information to make your own decision!

Okay, so, "anything you want" is perhaps an oversimplification. For starters, modern versions of macOS have a number of other protection systems in addition to SIP, such as TCC and AMFI. The thing is, once SIP is off, there is in theory nothing to stop a process from disabling those as well—who is going to stand in the way, when you can literally rewrite kernel memory? I suppose there are probably protected CPU registers and such.

  • Great explanation, thanks! Nov 15 '21 at 17:14

Disabling SIP will mean that apps that have been given root permissions will be able to modify system files, like how yabai modifies the files of the Dock. SIP usually protects these files from changes, so yabai has to have SIP disabled to modify the Dock to use advanced features.


System Integrity Protection (SIP) as defined by Apple.

System Integrity Protection (SIP) in macOS protects the entire system by preventing the execution of unauthorized code. The system automatically authorizes apps that the user downloads from the App Store. The system also authorizes apps that a developer notarizes and distributes directly to users. The system prevents the launching of all other apps by default.

Many developers (and some users) would disable SIP to let their apps work properly. Now, several years on, this is less necessary as most apps have found ways to do what they need to do without the need to disable SIP, allowing your Mac to stay more secure.

From Yabai's Requirements and Caveats section. (emphasis is mine)

System Integrity Protection needs to be (partially) disabled for yabai to inject a scripting addition into Dock.app for controlling windows with functions that require elevated privileges. This enables control of the window server, which is the sole owner of all window connections, and enables additional features of yabai. If you are running on macOS High Sierra 10.13.6, you can reenable SIP after the scripting addition has been installed.

I'm going to assume that this hold true for all OS's after 10.13.6. It looks as if you can re-enable SIP once the software is instead and set up, so you do not have to run it the entire time without SIP enabled. Hopefully and if possible, they will update the app to not require disabling SIP.

  • Hello! Thank you for your answer. I am looking for real-world examples, especially about security. For example, Chrome once made an update which inadvertently messed with /usr. This only effected people with SIP disabled. Jan 23 '21 at 23:53
  • I think you have misinterpreted the requirements. I don't think you can reenable SIP on macOS after 10.13 - certainly not 10.15 and 11. This was my experience with Finder addons Total Finder and XtraFinder which also use injection techniques.
    – Gilby
    Jan 24 '21 at 5:19
  • I myself have never disabled SIP on any of the machines that I operate on. But I can see issues with programs like how Chrome messed with /usr. I think an example is something kinda like the instance where someone was able to install runtime code into Transmission, or this more recent report of compiled Applescripts that were reported to infect computers in east Asia. In these examples, if SIP is disabled, a runtime could be placed in a protected directory where is appears to be normal.
    – ErniePC12
    Jan 24 '21 at 13:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .