Hi,Thanks for your help. I'll have to try that one later. For some reason the error disappeared, and it's not giving me a warning anymore. The code is the same as before. I'm pretty sure it got updated with Xcode the other day.In any case, thanks again.

Thanks! That' what I have found so far. I'm dong it by hand. Any of your three guesses would have done it.PS: I updated the question.

I had a copy in the bundle and on first run I copy the binary to the sandbox directory. The XPC service has access to its own sandbox and I copied the binary there. The folder in question is the one specified by the documentation. The url can be retrieved using FileManager.urls(...) - https://developer.apple.com/documentation/foundation/filemanager/1407726-urls

The system prevents a sandboxed process from creating executables [1]. It’s likely that this copy is the root cause of your problem. Why are you doing this copy? Why not run the tool directly from the bundle? How do I remove the quarantine? How do I get the system to put those process in the same sandbox the parent is using? I'm not running it from the bundle cause it fails from there as well, probably for the same reasons. More importantly, assume I want to download plugins from the internet, from my curated website, with helpers, and deploy them to ${sandbox}/Library/Plugins/. From what you're saying I wouldn't be able to run these?

Again, you have to be careful with your terminology. I'm pretty sure you are asking about the app's container folder here, not the actual sandbox, which is a runtime environment. I am being careful. You're wrong. I'm not asking about the app container folder, I'm asking about the sandbox as a whole set of constraints. I don't want my binary to have any extra permissions other than the ones the XPC will have. When your process spawns another process, by default, it inherits the same runtime sandbox. Great, the only problem is apparently you can't execute them. What is this "probably"? There is no "probably" in software development. Either you know the cause, or you don't.  Sorry you can put two and two together. Obviously I don't know the cause, I wouldn't be asking otherwise. Well that's a can-o-worms. What's the big picture here? Why are you sandboxing? Is this for Mac App Store deployment? Before you spend too much time on this idea, you have to make sure your app idea will pass App Review. App Review does have a category for "plugins" but it is up to you to interpret it and ensure that your app will comply. Apple won't "preclear" apps for App Review. I strongly advise making the "plugin" idea an optional afterthought that you can disable, if necessary, and still have a viable product. I don't care about distribution right now. Having a sandbox, regardless of distribution, is better for everyone, users, developers and other apps. In no case is hacking inside your app container a really good idea. I don't know what you mean by hacking. I need a process to do something. It's not short. It's not unlawful. So, all in all. Thanks for your answer: You are asking about a system restriction which you can't change. That’s all you had to say! The rest is unnecessary and unhelpful.