Sandbox-Bypassing IPC between App Intents and Launchd Daemons on macOS

We are designing a macOS utility that runs a local background agent via launchd (managing a local SQLite database and Unix socket). We want to expose controls (start/stop, status checks, CLI command invocation) to Siri via the App Intents framework.

Since App Intents typically execute within a sandboxed App Extension or a sandboxed App wrapper container:

What is the recommended IPC mechanism (e.g., Unix domain sockets, local HTTP/TCP ports, XPC) to securely communicate between a sandboxed App Intent extension and a non-sandboxed launchd helper daemon on macOS? Are there specific Entitlements (com.apple.security.temporary-exception.files.absolute-path.read-write or network exceptions) required to allow App Intents to talk to local UNIX sockets or loopback interfaces (127.0.0.1) without triggering sandbox violations? Can an App Intent directly invoke a helper command-line tool or launch a plist-configured service without bringing up the main application UI?

Answered by Frameworks Engineer in 891880022

I believe you could use HTTP or XPC to a privileged helper tool, but both would require user consent within the app process.

You can also configure your AppIntents extension to inherit the security permissions of app, so whatever access was granted by the app could be used by the extension, meaning the App itself does not need to run directly.

I believe you could use HTTP or XPC to a privileged helper tool, but both would require user consent within the app process.

You can also configure your AppIntents extension to inherit the security permissions of app, so whatever access was granted by the app could be used by the extension, meaning the App itself does not need to run directly.

How to handle loopback network permissions and Unix socket restrictions that block sandboxed App Extensions from talking to localhost?

Sandbox-Bypassing IPC between App Intents and Launchd Daemons on macOS
 
 
Q