7

I have a shell script I sometimes use to trigger Mission Control, which is simply the following:

#!/bin/sh
/System/Applications/Mission\ Control.app/Contents/MacOS/Mission\ Control

In macOS 13, this works fine.

In macOS 14, it crashes with the following:

Killed: 9

It appears that running any application in /System/Applications is now restricted in macOS Sonoma, unless SIP is disabled.

Is there a way around this without disabling SIP?

Improve this question
2
  • 1
    Could you give us some background to this, why you need a script to call Mission Control? You don't need a script to launch Mission Control ordinarily, it's key commandable from anywhere in macOS, I think Ctrl/ ↑ is default.
    – Tetsujin
    Commented Jan 4 at 18:48
  • @Tetsujin It's partly because sometimes I write scripts to trigger system functions like Mission Control that I can have a third party app run. But I'm the author of an app that can be configured to trigger Mission Control, app exposé, and "show desktop". I need a way to do it that works across all installations of macOS. Using keystrokes is unreliable because the user can change or disable them.
    – Bri Bri
    Commented Jan 4 at 18:59

2 Answers 2

Reset to default
10

Would this work for you?

#!/bin/sh
open -a "/System/Applications/Mission Control.app/Contents/MacOS/Mission Control"
Improve this answer
9
  • 2
    That does indeed work around the issue. Any reason why you're using -a instead of open "/System/Applications/Mission Control.app"?
    – Bri Bri
    Commented Jan 5 at 1:18
  • 1
    Can't you leave out the full path when you use -a, i.e. just open -a "Mission Control"
    – Barmar
    Commented Jan 5 at 15:11
  • 1
    I used the whole path so my script would emulate the OP's as closely as possible. As for the -a, I have several aliases in my .zprofile, such as alias gc='open -a GraphicConverter\ 12.app', and I will admit to a bit of copy-pasta: it worked whenever I first did it, so I kept using it. @nohillside's pointers have me curious now - I always learn from their posts.
    – Bruce Van Allen
    Commented Jan 6 at 2:16
  • 1
    open /path/to/foo is the same as double-clicking foo, this obviously also works with applications. open -a Foo.app uses the application register to launch Foo.app (no path required for standard applications). So, open -a "Mission Control" launches Mission Control, no need to add the path for this.
    – nohillside ♦
    Commented Jan 6 at 6:42
  • 1
    I'll add on to this answer to say that you can trigger "app expose" and "show desktop" with open "/System/Applications/Mission Control.app" --args 1 and open "/System/Applications/Mission Control.app" --args 2
    – Bri Bri
    Commented Jan 7 at 17:21
10

You already got a workaround, but the cause for this is Apple's "launch constraints". You can see this if you open Console.app and filter for AMFI while trying to spawn the binary in question:

AMFI: Launch Constraint Violation (enforcing), error info: c[1]p[1]m[1]e[14], (Constraint not matched) launching proc[vc: 1 pid: 10286]: /System/Applications/Mission Control.app/Contents/MacOS/Mission Control, launch type 0, failure proc [vc: 1 pid: 10286]: /System/Applications/Mission Control.app/Contents/MacOS/Mission Control

Apple documents some of the values that can show up in this log message, but in the specific case of c[1]p[1]m[1]e[14], all relevant info is essentially "reserved by the operating system".

But in general, this is a mitigation introduced by Apple to enforce that non-interactive system binaries can only be launched in ways that they expect, because there have been multiple security vulnerabilities in macOS that were based on running system binaries from paths they didn't expect, under a parent process from which they inherited certain properties, etc.

Improve this answer

You must log in to answer this question.

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