Hi bweinstein, yes I meant externally_connectable API. Is there any other way webpages can interact with the extensions or would it have to happen through content scripts injected into the webpage?

Can the script be run from within a container? if so what would be the restrictions on this script if it wants to talk to an external application which is not sandboxed through some IPC mechanism ? Would this work if I created an XPC service to launch the script as a child process ?

A script that you construct on the fly? Or a script embedded in your app’s bundle? The latter is definitely possible. The former is a bit trickier. Calling a compiled binary embedded in the app (sandboxed) as well as one residing externally in another directory My high level goal is to spawn and manage child processes of a binary from an XPC service. The binary would communicate with another app through IPC and send the messages over to the XPC service. These child processes would be long running. I wanted to know the possibility of launching binaries that are external to the sandbox and how would the IPC be different from launching a binary that is embedded within the sandbox?

A child process inherits the sandbox from its parent, and thus is subject to the same rules concerning IPC and so on. Could you elaborate a bit more here ? Are the rules for IPC different for an XPC service as compared to an app extension or app ?

@eskimo it should be able to run a nodejs executable file though right if not a shell script?

Can you step back and explain more about your high-level goal here? Based on your earlier posts it seems that you have a Safari web extension. That can’t ship independently, which means that you must necessarily have a container app. Beyond that it’s not clear how XPC Services and bundled executables come into the picture. Yes I am going to be running a Safari Web Extension and it is targeting the mac store. My assumption was, in order to run a binary outside of the app sandbox, I would need to either use a container app or an XPC service and not an app extension because of the privilege restriction. This binary would use named pipes to communicate with another process that is not sandboxed. I understand that the binary is going to inherit the sandbox of the parent app but is this feasible given a user allows filesystem permissions to the named pipe location?

No the unit tests are for the app extension piece that is bundled with the mac app.

@eskimo The external app outside the sandbox is run as a daemon process. The appex connects with this daemon process via xpc by machService name lookup

Hi @kichik you may have to use a content script to bypass this restriction