top of page
Search

Someone Built the Apple Intelligence Off Switch Apple Didn't Ship. Don't Let It Loose on Your Fleet.

Writer: MacSmithAI
MacSmithAI
Oct 7
7 min read

Apple's own position on Apple Intelligence, as of its macOS 27 enterprise notes published on 28 September 2026, is that "device management can restrict the use of Siri AI, Visual Intelligence, and Natural Language Calendar Event Editing." Restrict. Not remove. Flip every switch your MDM gives you and the models are still sitting on the disk, still occupying up to 14GB per machine.


Last week somebody closed that gap for you, and not in a way you'll enjoy. RemoveMacAI, an MIT-licensed command-line tool by an independent developer named Om Lahore, turns Apple Intelligence off on macOS 27 and deletes the on-device models, reclaiming about 12GB. MacRumors covered it on 5 and 6 October; AppleInsider, Cult of Mac, TechSpot and Slashdot picked it up the same week; John Gruber linked it on 6 October; and by 7 October 9to5Mac was arguing that Apple may have to support removal officially to protect Mac sales.


It is the week's most interesting Apple story — not because an indie script is big news, but because of the shape of the hole it exposes in Apple's management surface.


What the tool actually does

Two things, and keeping them separate matters.


First it disables features. Per the project's README: Siri including Hey Siri and the menu bar icon, Writing Tools, Genmoji, Image Playground, the ChatGPT extension, summaries in Mail, Messages, Safari, Notes and notifications, Mail smart replies, inline text predictions, Spatial Photos, Photos Clean Up, and Xcode predictive code completion. Its "what stops working" list also covers the Foundation Models framework, Visual Intelligence, and natural-language editing in Calendar.


Second — and this is the part no MDM does — it deletes the model assets. The README puts the recovered space at "about 12 GB"; MacRumors reported some users recovering over 20GB.


The mechanism is the interesting bit, and it is not what most admins assume when they hear "a script that rips AI out of macOS." It does not disable System Integrity Protection and it does not touch system files. The README states that no files under /System are modified directly and that SIP stays enabled, which Gruber confirmed in his own words: it "isn't rming files in the /System/ folder" and instead "uses techniques that work with System Integrity Protection remaining enabled."


What it actually installs is a configuration profile. The user gets the standard Device Management prompt in System Settings and has to click Install before the script will proceed to delete anything. According to AppleInsider's write-up, that profile carries both the documented restriction keys and settings that have no restriction key — and then, after the models are gone, it redirects attempts to re-download each removed model to a closed local port, so macOS cannot quietly pull them back on the next update. Reverting means removing the profile, which restores the previous settings and lets the models download again.


The parts that should stop you

Read the installer before you form an opinion, because it is a textbook example of a supply chain you do not control.


The documented install path is curl -fsSL piped straight into bash. The script checks that it is on Darwin and arm64, makes a temp directory, downloads a prebuilt removemacai-darwin-arm64.tar.gz and its companion .sha256 file from a GitHub release, compares the two with shasum -a 256, untars it, and executes the binary with < /dev/tty so it can take interactive input. Notably, the base download URL is overridable with a REMOVEMACAI_URL environment variable.


The checksum is worth a second look. Both the archive and its hash come from the same release location, so what that check proves is that the download was not corrupted in transit — not that the release itself is trustworthy. There is nothing in the README about code signing or notarization. This is a prebuilt binary with no documented signing or notarization, fetched over the network at run time from an endpoint an environment variable can change, which then installs a configuration profile that intercepts Apple's own asset downloads.


None of which makes the author a bad actor. The project is open source, the code is readable, the reversal path is real, and working inside SIP rather than against it is the respectable way to do this. But Gruber's own verdict is the one to borrow: he says he wouldn't run it on a production machine. Ten thousand managed Macs is ten thousand production machines.


Why your users want it badly enough to ignore you

Because the storage number is real and it is theirs, not yours.


Apple's requirements page, published 14 September 2026, says Apple Intelligence consumes up to 14 GB of storage on Macs with M3 or later and at least 12GB of unified memory, and up to 8 GB on other eligible models. Gruber's framing is the one your help desk will hear: on a Mac with "only 256 or even 512 GB of storage," a "dozen GB (or more)" "is meaningful."


None of that arithmetic is new — our macOS 27 post printed the same figures and told you to run a storage report. What is new is that there is now a one-command answer circulating in public, and the person most motivated to run it is the user on a three-year-old 256GB MacBook Air who has been ignoring the low-disk warning for a month and does not use Genmoji.


Restrict is not remove

Here is the comparison that matters, built only from what Apple and the project actually document.



MDM restriction (Apple's documented path)

RemoveMacAI (third party)

Turns the features off

Yes - the ones Apple names

Yes - including ones with no restriction key

Frees the 12-14GB of model storage

No

Yes - about 12GB

Stops the models downloading again

Not addressed on Apple's pages

Yes - redirects the download to a closed local port

Delivered by

Your MDM

A profile the user approves in System Settings

Supported by Apple

Yes

No

Reversible

Yes

Yes - by removing the profile


The row to sit with is the second one. Every control Apple hands you turns features off; none gives the disk space back. If storage reclamation is why someone wants Apple Intelligence gone, your MDM does not solve their problem, and you should say so plainly rather than implying a profile will.


One more thing worth being precise about. Apple's configuration enforcement documentation says that "configurations can be installed on devices using a device management service or manually by the users," and that "some configurations require installation using a device management service." Whether a user on your supervised, ADE-enrolled macOS 27 Macs can still approve a manually-installed profile like this one, and what happens when it collides with an MDM-delivered Intelligence configuration, is not answered anywhere on that page. Apple's macOS 27 enterprise notes do say that "device management can manage which apps or binaries are allowed to run" — but the page names no payload and no key for it, so treat that as a capability to go and test in your own tenant, not a control you can claim you have.


The procurement argument nobody at Apple wants to hear

The reason this is a news story rather than a curiosity is the argument Gruber and 9to5Mac are both making, and it is a procurement argument, not a storage one.


Gruber wrote that "there are institutional groups that have rules against AI," that those places "aren't allowing Golden Gate at all until and unless Apple Intelligence can be removed," and that the consequence is "not buying new Mac hardware that only runs Golden Gate." Ben Lovejoy's 9to5Mac piece on 7 October took that one step further: as future Macs drop support for older macOS versions, refusing to offer a removal path could eventually cost Apple hardware sales.


Both are opinion, labelled as such by both authors, and Apple has said nothing. But if you work in a regulated industry, a public-sector body or anywhere with a written no-generative-AI policy, you already know whether that describes you. If it does, this is the week to put the question to your Apple account team in writing — not because they will have an answer, but because a dated request on the record is how a documented gap becomes a documented feature.


The practical takeaway

Do not deploy this tool, and do not let it spread by itself either. In order:


Block it, then measure it. Add RemoveMacAI to the unsanctioned-tooling list you should already be maintaining, and go look for the configuration profile it installs — a user-approved profile on a managed Mac is a detection you can build today, and it is a far better signal than hunting for a binary that deletes itself from a temp directory.


Separate the two asks. "Turn Apple Intelligence off" is something your MDM can largely do, within the limits Apple documents. "Give me 14GB back" is something it cannot do at all. Answer those as two different tickets, because conflating them is what makes a user go looking for a script.


Run the storage report, and this time act on the tail. If you have a population of 256GB Macs sitting under 20GB free, that is the population that will run an unverified binary from the internet to fix it. Upgrading or re-imaging thirty machines is cheaper than discovering a third-party profile on three hundred.


Put the removal question in writing to Apple. One paragraph, dated this week, asking for a supported way to remove the on-device models on managed Macs. If the Gruber argument has any force, it comes from enterprise customers asking — not from bloggers.


The thing not worth doing is treating this as a story about one developer's script. The script will be fine, or it will break and be patched; either way it is not the point. The point is that Apple shipped an AI platform with a restriction surface and no uninstall, and the market has now demonstrated — in one command, in one week — how much demand there is for the half Apple left out.



Comments

bottom of page