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.
Topic:
App & System Services
SubTopic:
General
Tags: